sensitive data protection in dbaas
TRANSCRIPT
1
1 INTRODUCTION
Database-as-a-service (DbaaS) is a cloud computing service model that provides users
with some form of access to a database without the need for setting up physical
hardware, installing software or configuring for performance. All of the administrative
tasks and maintenance are taken care of by the service provider and the user or the
application owner needs to do is to use the database. The outsourcing of data can lead
to confidentiality and integrity issues and also privilege escalation.
2 CHALLENGES
The security and privacy challenges can be viewed in two perspectives, one by the user
using the DBaaS for an organization and the other by the end user of the organization.
The major concern in providing security in DBaaS is to protect the cloud database from
the Malware and Intruder attacks. Encryption of data provides confidentiality but not
data integrity. In addition, performing query over the encrypted database is also a
challenge.
The security can be provided by using authentication mechanism followed by
access control mechanism which is responsible for providing data integrity. The access
control mechanism requires strict policies and constraints which are used to restrict the
user to access the sensitive data. But the access control mechanisms also suffer from
challenges like:
1. Maintaining the role hierarchy.
2. Providing secure session management.
3. Protecting from the privilege escalation.
3 EXISTING WORK
Hacigumus et al. (2002) proposed a method for executing SQL query over Encrypted
Data. Symmetric encryption is used for the encryption of each tuple and an index is
added to each and every tuple. But this solution does not support performing range
queries over encrypted databases. Agrawal et al. (2004) proposed an Order Preserving
Encryption (OPE) method that works only for the numeric data and it uses bucketization
technique using the MySQL database and works at server side. The drawback of this
2
method is it reveals the relation of plaintext and ciphertext. So to overcome this
problem the ideal security for order-preserving scheme was proposed by Boldyreva et
al. (2011). The attacker cannot get any information about the plaintext by accessing the
cipher texts. The goal to achieve the security notion of OPE is to maintain the order and
do not leak any information besides the order. These solution do not secure the
information beside the order leak. So, Kadhem et al. (2010a), Kadhem et al. (2010b)
and Yum et al. (2012) proposed the OPE solutions to provide security from order leak.
But still these OPE solutions are having limitations of data leak beside the order and
the data encryption method does not provide the integrity solutions. Access Control
mechanism is required to provide the integrity and authentication.
Brodersen et al. (2004) proposed a solution Siebel role based access control
mechanism that allows multiple tenants, in which each tenant is the owner of his
separate virtual database.
Calero et al. (2010) proposed a model for authorization that supports multi-tenancy
role-based access control that used path back object hierarchy. Hu et al. (2009)
proposed ontology-based distributed role base access control for the cloud computing.
It provides different access policies for different resources.
Yaish et al. (2011) have proposed a multi-tenant database access control
mechanism, called Elastic Extension Table Access Control (EETAC). It allows each
tenant with a different type of access grants to access data in the multi-tenant database
for which the extra virtual table is created to store the information.
4 MOTIVATION
The confidential data leakage infects many of the computing systems. The confidential
information in any database is user's private information like financial data, medical
data, and government document related data. The OPE encryption mechanism that
provides confidentiality can perform range query over the encrypted databases. But
OPE solutions do not secure data against the attacks like IND-CPA attacks and the big
jump attack.
The existing work uses role based access control for providing confidentiality and
integrity. But these access control mechanisms do not provide protection against the
privilege escalation and the SQL injection and also role hierarchy is not maintained.
3
The limitations of the existing work motivate to work on a solution in which
database will be secured from the attacks like IND-CPA, Big jump, SQL injection and
Privilege escalation.
5 OBJECTIVES
The objectives of the work are:
1. To protect sensitive data from attackers and to provide data confidentiality using
strong encryption method to perform efficient queries like range, SUM, AVG,
etc. over the encrypted database.
2. To provide separate privilege access to a user's query which maintains the role
hierarchy and to provide protection from the privilege escalation.
6 PROPOSED SOLUTION
The main security risks present for databases in the cloud environment are the
confidentiality and integrity issues and unreliable access control mechanisms for
accessing the sensitive data. In this work, the sensitive data of the query is encrypted
and stored in the database with a proper role base access control that manages the
session of the query and maintains the role hierarchy. This work is done in two parts:
1. Sensitive Data Encryption in the Query: The Sensitive Data Protection of
DBaaS is done by encrypting the query at the client side. The database is secured
by encrypting the query, and the sensitive information is stored without any
information leak. The query encryption takes place at the client machine before
sending to Database server. A two layered encryption mechanism, Format
Preserving Encryption (FPE) followed by OPE is used to preserve sensitive
information. One layer encryption using OPE is used for protecting non-
sensitive data. It maintains the order in an encrypted database and so range query
can be performed over encrypted database using an encrypted query.
2. Role Based Access Control: The query is granted with least access privileges,
and a session key is used for session management that is generated after the user
authentication. It also protects data from privilege escalation and SQL injection
4
attacks. It uses the partial homomorphic encryption (Paillier Encryption) for
encrypting the sensitive data in the query. If a query is to perform any operation
on sensitive data, then extra permissions are required for accessing sensitive
data. Data confidentiality and integrity are achieved by using the role-based
access control with partial homomorphic encryption.
6.1 Architecture
This work has two main modules as shown in figure 1:
1. Client-side module: - It has two sub-modules that are related to the client side
query encryption. The modules are:
a. Sensitive data encryption: - It uses user's secret key and OPE and FPE
Encryption algorithms.
b. Query Encryption: - Encrypting the complete query using the session
key for the secure communication.
Figure 1. Architecture Diagram
2. Server side module: - The responsibility of this module is to provide
authentication of the user and the Role Based Access Control (RBAC) to the
users query on the server.
a. Authentication: - It checks the user credential and validate the user.
After validation of user, it issues the session key.
b. RBAC: - It provides least privileges to the user's query and encrypt the
query using Paillier encryption before executing the query. It has the
following sub modules:
i. Query Decryption: Decrypt Query Using session key.
5
ii. Get User Role: Get the list of all the roles.
iii. Activate Role: This module activates the appropriate user role
for the execution of the query.
iv. Encrypt: It perform query Encryption.
v. Result Handler: - It responsible for executing the query and get
query result.
vi. Deactivate Role: -It will deactivate the activated role of the user.
6.2 Client Side Protection
The client side protection focuses to secure the sensitive data in the query and to execute
over the encrypted database. The client side encryption is done such a way that the
encrypted query can perform range query over the encrypted database. A two layered
encryption mechanism is used for sensitive data, and a single layer encryption is used
for non-sensitive data. OPE is used for single layer encryption. It maintains the order
in an encrypted database because of Lazy sampling algorithm that generates the ordered
random number, and so range query can be performed over encrypted database using
an encrypted query. The drawback associated with OPE is the attacker can guess the
value based on the ordering of data. So, for sensitive attributes in the database, a double
layered encryption using FPE followed by OPE symmetric key encryption algorithm is
used.
6.2.1 Threat Model
In the threat model, the external threat and insider threat such as curious database
administrator who have access to the database are considered. The assumptions are:
1. The attacker performs a passive attack i.e., an attacker can access the only
ciphertext and the data are not modified.
2. The cloud database is stored on the untrusted server.
At the cloud provider end, the attacker can log all the client communications, can read
unencrypted data, and try to break the encryption of making the copy of encrypted data.
The attacker can make the copy of the VM of the host. Figure 2 demonstrates that once
the attacker get the server access then he can access to query, result, database and cache.
6
Figure 2. Block Diagram of Threat Model
The cryptography attacks done by attackers are classified according to different levels.
Level 1: Ciphertext-only attack
Level 2: Known plaintext attack
Level 3: Chosen-plaintext attack
6.2.2 Securing Sensitive Data
This two layered encryption is performed using single key which is provided by the
database service provider. This single key is further split into two keys one is for single
layered and other for two layered encryptions using a key splitting algorithm. The key
splitting algorithm uses the randomized algorithm which is seeded with a known value.
This work performs all computing like encryption and decryption at client side which
protect from the insider attacks and cryptographic vulnerabilities of encryption
Figure 3 depicts the query processing framework in which the SQL operations are
performed by the user. The sensitive and non-sensitive data of the query are
differentiated based on the attributes by the proxy. The proxy contains the list of
sensitive and non-sensitive attributes. It transforms the plaintext query to cipher text
query and also checks the validity of that query by checking whether the query is correct
or not according to the database used. It then sends the valid query to cloud server.
Then, based on the query the server returns the result to query proxy which decrypts
the query and gives the plaintext result to the user.
7
Figure 3. Block Diagram of Query Processing
The basic idea of the Query proxy module is illustrated in figure 4. It checks whether
the queried attribute is sensitive or not, if it is a sensitive attribute, then data should be
encrypted by FPE followed by the OPE. The keys for FPE and OPE are different and
are generated using a randomized key splitting algorithm. The value of key1 and key2
generated from the splitting algorithm depend on the seed value, so if the seed value is
changed, then the value of the keys generated is changed as well. The key1 is used for
FPE and for OPE key2 is used. For non-sensitive attribute only one layer of encryption
is used. There is no requirement splitting of keys since only one key is used.
Figure 4. Block Diagram of Client Side Process
8
The following are the assumptions of the work:
1. The datacenter and the database server are not trusted.
2. The client is trusted and it will not be compromised.
3. The communication channel is assumed to be secured between client and server.
The proxy solution is as follows:
Step 1: Select the attributes that contain sensitive data in the query.
Step 2: If (Query contain sensitive data):
2.1 Split the n bit key to two n/2 bit key.
2.1.1 Generate the random seed value.
2.1.2 Store the seed value on client machine.
2.1.3 Based on seed value select n/2 bits for key 1 and remaining n/2
bits for key 2.
2.2 Encrypt the sensitive data using FPE which is using fiestel network to
encrypt the data using key one.
2.3 Encrypt the data using OPE using key two which use lazy sampling
algorithm.
else:
2.1 Do not split key.
2.2 Encrypt the data using OPE using the main key that use lazy sampling
algorithm.
Step 3 Regenerate the query.
6.2.3 Order Preserving Encryption
OPE is a deterministic encryption scheme whose encryption function preserves
numerical ordering of the plain texts. This scheme is one of the class of encryption
algorithms that supports range queries over encrypted databases. It has the following
condition:
Enc(x)>Enc(y) iff x>y
Step 1: Find the plaintext space, ciphertext space, plaintext length and ciphertext length.
Step 2: Generate ciphertext using the step 1 values, and secret key using AES
encryption with CBC mode.
9
Step 3: Calculate probability using the hypergeometric distribution.
Step 4: Transform the cipher text value to the ordered encrypted value.
6.2.4 Format Preserving Encryption
The FPE encrypts the data in such a way that the plain text space and the ciphertext
space is same. Its goal is to perform encryption on sensitive data under the control of a
symmetric key K, deterministically encrypt a plaintext X into a ciphertext Y that has
the same format as X.
6.2.5 Query Transformation
The database contains attribute such as the sensitive and non-sensitive data. A single
layer of encryption is performed on non-sensitive data but in case of sensitive or private
data two layers of encryptions namely FPE followed by OPE are performed. OPE
allows the processing of equality and order prediction completely at the server side on
the non-sensitive encrypted data. OPE process constructs like MIN, MAX, ORDER BY
etc., at server on the encrypted data.
6.2.6 Query Processing
The user submits the query as plaintext to the client side query proxy to check the
validity of the query. If query is valid then it transforms the query to an equivalent
encrypted relation.
Some of the transformations that are to be done during rewriting of these queries
are as follows:
1. All the constants in the query are replaced by their appropriate encryption.
2. Relation names and column names are replaced by the assigned name.
3. The ADD, SUM, AVG cannot be calculated on the sever end on the encrypted data
because of OPE.
6.3 Server Side Role-Based Access Control
The server side protection contains an access control module and a sub module at client
side for query encryption to provide secure communication between client and server.
10
The access control module is divided into two main sub modules authentication sub
module and RBAC sub module.
The RBAC provides security from the unauthorized access. It supports three
security principles: least privilege, data abstraction, and separation of duty for DBaaS
with query encryption support. The least privilege principle requires a user's query to
be authorized to execute only the minimal set of permissions needed for a given task,
as determined by role. The separation of duty principle states that no user should be
given sufficient permissions to misuse the system. The block policies are created based
on authorization constraints and the allow policies are provided explicitly to the RBAC.
This works as follows:
1. The authentication mechanism creates the session key for the session management
for the RBAC.
2. The group authentication mechanism helps to protect unauthorized group access.
3. It supports role hierarchy management that help to provide the least privilege when
any role is disabled or deleted by the admin.
4. The query encryption is performed using the Paillier encryption.
6.3.1 Proposed Solution
The authentication module is responsible for the user authentication and generation of
the session key. Session key is generated using the Secure Hash Algorithm (SHA-2)
after the validating user and is used for secure communication. Queries are validated
by the access control module and are redirected to the database for further processing.
The access control module takes encrypted query, group key (if any group is assigned)
and optional requests from users as well as it takes user id and session key as input from
authentication module which contains sub-modules as shown in figure 5. The
administrator is responsible for the maintenance of the role hierarchy in the access
control mechanism.
Figure 5. Block Diagram of Architecture
11
Figure 6. Flow Diagram of Access control Module
The working of server side access control mechanism (figure 6) is as follows:
Step 1: Query Handler takes the input as encrypted query and optional information such
as group keys and activation request. It decrypts the information using the session key.
Step 2: The Get User role take input all the information and process it. It collect all the
role information that belongs to a user.
Step 3: If (User belongs any group):
3.1 if (Authentication of group using group key is successful):
3.1.1 Go to Step 4.
3.2 else:
3.2.1 Discard.
else:
3.1 Go to Step 4.
Step 4: Create the set of Individual Roles.
Step 5: If (User does not belong group role and individual roles):
5.1 Discard the Query.
12
else:
5.1 Go to Step 6.
Step 6: Prepare the complete set of individual roles and the group roles.
Step 7: Select a role or create a temporary role that will have sufficient permission to
execute the query. Activate the selected role by adding the required sets of the
permissions.
Step 8: Create the set of accessible columns for the user.
Step 9: If the set of queries columns belongs to accessible columns list then trigger to
regenerate query otherwise discard the query.
Step 10: Regenerate the query by encrypting the sensitive data using the Paillier
encryption.
Step 11: Execute the query on the encrypted database.
Step 12: If Result handler sends the encrypted result to the user and sends a trigger to
deactivate the activated roles.
Step 13: Deactivate the all activated role by removing all permission sets.
7 EXPERIMENTAL SETUP
The experimental setup uses Open Nebula for the cloud setup and for Database server
MySQL cluster is used. The experiment is performed by creating ‘n’ tenants with the
fixed IP addresses and each tenant contains up to ‘m’ number of users. The client side
seed value is of 128 bits and secret key is of 256 bits long. The server side session key
of 512 bits which is generated by using SHA. The length of the public and private keys
for the query encryption used at the server side is 256 bit. The sensitive data column
name is given as input to the proxy and so the application will perform two layered
encryption on the sensitive data by the proxy. The TPC-H dataset is used in which the
user selects the sensitive column for sensitive data. Each user has their client-side proxy
and each tenant has their own RBAC mechanism.
8 RESULTS AND SECURITY ANALYSIS
8.1 Attacks for Client Side Solution
1. Indistinguishable chosen plaintext attack: It comes under the Chosen-Plaintext
Attack (CPA). It is an attack model for cryptanalysis that presumes that the
13
attacker can obtain the ciphertexts for arbitrary plaintexts. The goal of the attack
is to gain information that reduces the security of the encryption scheme.
2. Big jump attack: The big jump attack is used to find the relation of ordered
encryption pairs. The message xi and xj matching pair namely, si, j and sj, i, can
be retrieved to reconstruct the relation (xi < xj or xi > xj).
8.1.1 Result Analysis
The client query encryption work is secure from the major attacks line IND-CPA. The
attacker has the probability of guessing the correct encrypted message from the
arbitrary set of plaintext messages is less than ½ for the IND-CPA attack Oracle game
and mathematically proved that
𝐴𝑡𝑡𝑎𝑐𝑘𝑒𝑟𝑆𝐸,𝐸𝑁𝐶𝐼𝑁𝐷−𝐶𝑃𝐴 <
1
2
The big jump attack model attacker is vulnerable to the OPE but two layered approach
the order is removed by FPE and then OPE is applied on it. Therefore, the ciphertext
looks like a ciphertext generated after the OPE but there is no order relation between
the ciphertexts. So the attacker cannot guess that left plain text is encrypted or right
plaintext encrypted.
Experiments are conducted using the SQL query such as Equality, Range, Delete,
Join, Insert, Update set and update increment queries using MYSQL and double layered
encryption. Figure 7 shows the comparison results of number of queries processed and
figure 8 shows the impact of varying the number of users.
Figure 7. Graph Query verses Time Figure 8. Number of Users
Verses Time
0
10
20
30
40
50
No
qu
ery
pro
cess
es p
er
seco
nd
Queries
Mysql Dual Layred
300
350
400
450
500
550
600
650
700
Tim
e
No of Users
Mysql Dual layered
14
The time for executing a query is computed by adding the query encryption time
with query execution time and response time. Even though most of the computations
of a query are done at the client end, from the table 1, it was observed that total time
taken for a query execution using MYSQL is less than double layered encryption.
Table 1. Execution Time of Query
Query and Scheme Mysql Dual layered approach
Equality 0.07112 sec 0.09071 sec
Join 0.075 sec 0.1016 sec
Range (Only on OPE columns) 0.09146 sec 0.14327 sec
Delete 0.01532 sec 0.02103 sec
Insert 0.03013 sec 0.04162 sec
Update 0.03003 sec 0.05 sec
8.2 Server Side Access Control Attacks
1. Privilege escalation: Privilege escalation means a user receives privileges (to
perform any operation on the database) they are not entitled to. These privileges
can be used to delete data, view private information, or update unwanted
information. Privilege escalation occurs in two forms i) Vertical privilege
escalation ii) Horizontal privilege escalation.
2. Jailbreak: A jailbreak tool used to perform the act of breaking out of a chrooting
or bypassing digital rights. It allows the user to see data outside of the file system
that the administrator intends to make available to the application. So, it uses
the file extension of the database to exploit the database access control.
3. SQL injection: For performing the SQL injection, the SQLmap tool is used.
SQLMAP is the open-source penetration testing tool that automates the process
of detecting and exploiting database SQL injection flaws. So, for exploiting the
query access control, this tool is used to perform SQL injection on DBaaS.
15
8.2.1 Security Analysis and Result
The server side attacks are related to privilege escalation, session management and the
role hierarchy management. In this work, attacks are reduced due to the role hierarchy
management with least privilege grant by adding minimum permissions for query
execution. The activation and deactivation functions play a major role to protect from
the escalation attack because by default roles are considered as deactivated roles and
both functions need a user id to activate the role. The Paillier encryption algorithm is
used to encrypt the sensitive data. So the sensitive data is secured during the execution
of the query as well as in a database. Since the pallier encryption has the properties of
homomorphic encryption and works on the public-key cryptosystem, it protects the
sensitive data from the cryptographic attacks such as chosen-plaintext attacks (IND-
CPA) and adaptive chosen-ciphertext attacks (IND-CCA2).
Figure 9. Access Time Vs Number of query
Figure 10. Activation and Deactivation Time Vs Number of Query
16
Experiments are conducted using twenty-five different roles and eight groups are
created for the tenant’s database user. For the analysis, three type of queries are tested
i) sensitive and non-sensitive data in query ii) only sensitive data in query iii) non-
sensitive data in the query. The database has four sensitive data columns. Figure 9
shows number of queries vs. query access time and it is observed that there is little
difference between query access time of sensitive data and non-sensitive data. This
difference is due to extra computation time needed for sensitive data encryption.
However this overhead provides the data confidentiality for the database owner. The
role activation and deactivation time is represented in figure 10. The role activation
function and deactivation is responsible for providing integrity feature for proposed
work. The role activation time is calculated by considering a maximum of 8 roles of the
users and 3 groups of users. The queries contain sensitive attributes which need some
extra permission that is required for the role activation.
9 CONCLUSION
This work provides confidentiality, integrity and secured access control mechanism for
the DBaaS, which includes client side and server side protection. On the client side,
the Sensitive Data Protection of DBaaS is done by using OPE and FPE for encrypting
the database and securing the query at the client machine. It supports all large range of
TPC-H queries that will use MYSQL database and provides security against the IND-
CPA and big jump attacks. Server Side mechanism is a Hierarchical Role-Based Access
Control with Homomorphic Encryption for DBaaS which provides access control for
the multitenant database system. In this approach, the query is granted with least access
privileges, and a session key is used for session management. It also maintains the role
hierarchy and protects data from privilege escalation and SQL injection.
References
Agrawal, Rakesh, Jerry Kiernan, Ramakrishnan Srikant, and Yirong Xu. (2004)
Order preserving encryption for numeric data In Proceedings of the 2004 ACM
SIGMOD international conference on Management of data 563-574. ACM.
Boldyreva, A., N. Chenette, and A. O’Neill (2011) Order-preserving encryption
revisited: Improved security analysis and alternative solutions in Advances in
Cryptology–CRYPTO 2011 578–595 Springer.
17
Brodersen, K., T. M. Rothwein, M. S. Malden, M. J. Chen, and A. Annadata
(2004) Database access method and system for user role defined access US Patent
6,732,100.
Calero, J. M. A., N. Edwards, J. Kirschnick, L. Wilcock, and M. Wray (2010)
Toward a multi-tenancy authorization system for cloud services in IEEE Security &
Privacy 8(6), 48–55.
Echeverria, V., L. M. Liebrock, and D. Shin (2010) Permission management
system: Permission as a service in cloud computing in Proceedings of the 2010 IEEE
34th Annual Computer Software and Applications Conference Workshops 371–375
IEEE Computer Society.
Hacigumus, H., B. Iyer, and S. Mehrotra (2002) Providing database as a service in
18th International Conference on Data Engineering. 29–38 IEEE.
Hu, L., S. Ying, X. Jia, and K. Zhao (2009) Towards an approach of semantic access
control for cloud computing in Cloud Computing 145–156 Springer.
Kadhem, H., T. Amagasa, and H. Kitagawa (2010) Mv-opes: Multivalued-order
preserving encryption scheme: A novel scheme for encrypting integer value to many
different values in IEICE TRANSACTIONS on Information and Systems 93(9), 2520–
2533.
Kadhem, H., T. Amagasa, and H. Kitagawa (2010) A secure and efficient order
preserving encryption scheme for relational databases. In KMIS 25–35.
Yaish, H., M. Goyal, and G. Feuerlicht (2011) An elastic multitenant database
schema for software as a service in IEEE ninth international conference on
Dependable, autonomic and secure computing (DASC), 2011 737–743 IEEE.
Yum, D. H., D. S. Kim, J. S. Kim, P. J. Lee, and S. J. Hong (2012) Order-preserving
encryption for non-uniformly distributed plaintexts in Information Security
Applications 84–97 Springer.
18
PROPOSED CONTENTS OF THE THESIS
CHAPTER 1 INTRODUCTION
1.1 Database as a Service
1.2 Threat
1.3 Challenges
1.4 Database Encryption
1.5 Access Control
1.6 Objectives
1.7 Contribution
1.8 Thesis Organization
CHAPTER 2 EXISTING WORK
2.1 Secure Computation
2.2 Encryption Techniques
2.2.1 Order Preserving Encryption
2.2.2 Format Preserving Encryption
2.2.3 Partial Homomorphic Encryption
2.2.4 CryptDB
2.3 Access Control
2.3.1 Privacy-Preserving Access Control
2.3.2 Authorization Mechanisms
2.3.3 Siebel Access Control
2.3.4 Elastic Extension Table Access Control
2.3.5 Access Control as a Service
2.4 Limitations
2.4.1 Encryption
2.4.2 Access Control
CHAPTER 3 MOTIVATION AND ARCHITECTURE
3.1 Motivation
3.2 Architecture
3.3 Key Management
CHAPTER 4 CLIENT SIDE PROTECTION
4.1 Introduction
19
4.1.1 Order Preserving Encryption
4.1.2 Format Preserving Encryption
4. 2 Threat Model
4.3 Securing Sensitive Data
4.3.1 Key Splitting
4.3.2 FPE Module
4.3.3 OPE Module
4.4 Query Transformation
4.5 Query Processing
4.6 Attacks Considered
4.6.1 Indistinguishable Chosen Plaintext attack
4.6.2 Big Jump Attack
4.7 Security Analysis and Result
4.8 Summary
CHAPTER 5 SERVER SIDE PROTECTION
5.1 Introduction
5.1.1 Role Based Access Control
5.1.2 Role Hierarchy
5.2 Proposed work
5.2.1 User Query Access Function
5.2.2 Get User Roles Function
5.2.3 Activate and Deactivate Permission Function
5.2.4 Get User Columns Function
5.3 Access Control Attacks Considered
5.3.1 Privilege Escalation
5.3.2 SQL Injection
5.4 Implementation and Analysis
5.5 Summary
CHAPTER 6 CONCLUSION AND FUTURE WORK
APPENDIX-A
REFERENCES
20
LIST OF PAPERS SUBMITTED ON THE BASIS OF THE THESIS
PRESENTATION IN CONFERENCES
1. Kamlesh Kumar Hingwe and S. Mary Saira Bhanu (2014) Two layered
protection for sensitive data in cloud. International Conference on Advances in
Computing, Communications and Informatics (ICACCI, 2014), IEEE, Delhi,
Sept. 2014, pp. 1265-1272.
2. Kamlesh Kumar Hingwe and S. Mary Saira Bhanu (2014) Sensitive Data
Protection of DBaaS Using OPE and FPE. Fourth International Conference of
Emerging Applications of Information Technology (EAIT- 2014), IEEE,
Kolkata, India, Dec. 2014, pp. 320-327.
3. Kamlesh Kumar Hingwe and S. Mary Saira Bhanu (2015) Hierarchical
Role-Based Access control with Homomorphic Encryption for Database as a
Service. International Conference on ICT for Sustainable Development
(ICT4SD), Ahmedabad, India, July 3-4 2015, Springer.