SECURE QUERY PROCESSING in CLOUD NoSQLcs.ucf.edu/~ahmadian/pubs/ICCE2017 Presentation.pdf ·...

SECURE QUERY PROCESSING in CLOUD NoSQL

Mohammad [email protected]

University of Central Florida

April 9, 2017

Mohammad Ahmadian (UCF) Secure NoSQL April 9, 2017 1 / 42

Research goal is to find an answer to:

Is it possible to delegate processing of a private data to third-partywithout getting revealed?

Outline

1 Introduction & motivationNoSQL data models

2 Cryptosystems for outsourced data

3 Threat Model

4 RELATED WORK

5 JSON And BSON

6 SecureNoSQL-contributions

7 Future work

8 References

Introduction

DBaaS is a cloud-based approach to the storage and management of structured data.DBaaS delivers all database functionality plus benefited from being cloud-based to provide:

1 Flexible, scalable, on-demand platform

2 Easy management, self-service, provisioning

3 Performance monitoring and data analytics information

4 The environmental benefits of moving to the cloud

5 Charge back for database usage

Cloud database a a service

There are two groups of database services in the cloud DBaaS portfolio:

Relational Database

NoSQL (Not only SQL)

That was kind of hard to imagine to have a time without relation database because of manybenefits it brought such as persistence, integration, SQL, concurrent transactions.RDBMS also have some problems:

DBaaS - RDBMS cons I

1- Impedance mismatch

Mapping logical objects to tables andvice versa creates a performancedisadvantage when you have complexdata Mapping objects to tables.

DBaaS - RDBMS cons II

2- Scalability

Scale up vs scale outExpensiveHard to maintainTechnical limitsSingle Point OfFailure

ReliabilityEasy to growEasy to maintainFlexible

Scale out

(Horizontal)

Introduction- Cons of DBaaS

According to 2016 report of Cloud Security Alliance (CSA), data securityis the main preventative reason for organizations to avoid cloudcomputing.

Introduction- Data Models For NoSQL

Data Models For NoSQL Databases:1 Key-value stores: A dictionary DS where a key uniquely identifies the value.

2 Column-family stores: Data are stored in rows and each row has a unique key and set ofcolumns.

Introduction- Data Models For NoSQL

Data Models For NoSQL Databases:1 Key-value stores: A dictionary DS where a key uniquely identifies the value.

2 Column-family stores: Data are stored in rows and each row has a unique key and set ofcolumns.

Introduction- Data models for NoSQL

3 Document stores: Data are stored in internal structure (Document) to offer higher levelof granularity. Each document has a unique key to identify.

4 Graph Databases: This model is based on graph and can used to represent complexstructures and highly connected data.

Introduction- Data models for NoSQL

3 Document stores: Data are stored in internal structure (Document) to offer higher levelof granularity. Each document has a unique key to identify.

4 Graph Databases: This model is based on graph and can used to represent complexstructures and highly connected data.

Cryptosystems for outsourced data

Data in the cloud can be in one of three states:1 Store: Encryption of data before uploading to the Cloud.

2 Transit: Communication channels can be secured by using the standard HTTP overSecure Socket Layer (SSL). In addition, the endpoint authentication feature of the SSLprotocol makes it possible to ensure clients are communicating with an authentic cloudserver.

3 Process: Data owner should disclose decryption key to the server in order to decrypt thedata before performing any required operation. The problem is when the decryption key iscompromised, the data confidentiality would be affected. Therefore, in the cloudcomputing model, new set of cryptosystems is required.

Threat models

Threat Model: We investigate cloud threat model from the adversarial prospectivewhich is a holistic process based on end-to-end security. The model identifies two classes ofthreats.

External attacker:An attacker from the outside of cloud environment might obtainunauthorized access to the data.

Cloud malicious insiders: Unauthorized access to data by the cloud internals

Threat models

Threat Model: We investigate cloud threat model from the adversarial prospectivewhich is a holistic process based on end-to-end security. The model identifies two classes ofthreats.

External attacker:An attacker from the outside of cloud environment might obtainunauthorized access to the data.

Cloud malicious insiders: Unauthorized access to data by the cloud internals

Cryptosystems-Deterministic (DET)

DET scheme always produces the same ciphertext for an identical pair of given plaintext and key.1

DET leaks information about ciphertext of same plaintext. DET enables server to process pipelineaggregation stages such as group, count, retrieving distinct values and equality match 2 on the fieldswithin an embedded document. The embedded document can maintain the link with the primarydocument through application of DET encryption. See Equation 1.

Deterministic Encryption

for j = 1 . . . n; Cj = Ek(Pj); Pj = Dk(Cj) (1)

1Block ciphers in Electronic Code Book (ECB) mode with a constant IV are DET.2Equality matches over common fields in an embedded document will select documents in the collection

containing fields with specified values.Mohammad Ahmadian (UCF) Secure NoSQL April 9, 2017 13 / 42

Cryptosystems-Random (RND)

RND scheme (probabilistic) encryption, the same message with the same key yields differentciphertext.This randomness provides the highest level of security and different encryption algorithms

provide RND property. 3 RND type schemes are semantically secure against chosen plaintext attacksand hides all kind of information about ciphertext. RND scheme does not allow any efficientcomputation on the ciphertext.4

Random Encryption

C1 = Ek(P1 ⊕ IV ), P1 = IV ⊕ Dk(C1)

for j = 2 . . . n; Cj = Ek(Pj ⊕ Cj−1), Pj = Cj−1 ⊕ Dk(Cj)(2)

3AES in Cipher Block Chaining (CBC) mode is used for RND. AES with a key size of 128,192 or 256 bitsand with a block size of 128 bits.

4Where: Ek is the Enc., Dk is the Dec., k is secret key P is plaintext and C is ciphertext.Mohammad Ahmadian (UCF) Secure NoSQL April 9, 2017 14 / 42

Cryptosystems-Order-Preserving Encryption (OPE)

OPE projects the order relation between plaintext data elements to their ciphertext values. OPE leaksthe order of ciphertext, so it supports a lower degree of security.

Order-Preserving Encryption

∀x , y |x , y ∈ Data Domain

x < y =⇒ OPEk(x) < OPEk(y)(3)

An efficient inequality comparisons on the encrypted data elements can be performed by applying OPEwhich supports range queries, comparison, Min(), Max() on the ciphertext.

Cryptosystems-Additive Homomorphic Encryption (AHOM)

AHOM allows the server to conduct computations on ciphertext with the final result that get decryptedat the proxy. In spite of sustained research efforts of the Fully Homomorphic Encryption (FHE),there is no efficient FHE, except for limited operations. We applied Paillier [1] scheme that supportsadditive operations. It should be noted that m1,m2 are messages to be encrypted where m1,m2 ∈ Zn.r1, r2 ∈ Z∗

n are randomly selected.

Additive Homomorphic Encryption

(Ek(m1, r1)× Ek(m2, r2)modn2

)= m1 + m2(mod n) (4)

In other words, the product of two ciphertexts decrypt to the sum of their corresponding plaintexts.

RELATED WORK

The first SQL-aware query processing over encrypted database was CryptDB [2].CryptDB satisfies data confidentiality for the relational database. However, CryptDBcannot perform queries over data encrypted with different keys. Other problem thatCryptDB has is information leakage from encrypted data.

A practical searchable security scheme known as Oblivious Cross Tags (OXT) isintroduced by Cash et al. [3] which can search on encrypted data sets in sub-linear timecomplexity by using different types of indices, however it is not practical on NoSQL datasets which are designed to scale to millions of users doing updates simultaneously.

Extended OXT introduced by Faber et al. adds a set of new features such asmulti-keyword, wild-cards and substring searching to the basic OXT approach.

SecureNoSQL is a system which acts as a proxy to secure the communication between theNoSQL database server, and the applications server. Advantages: Using originalexpressive query language. Benefits from secondary indexes of database system [4].

RELATED WORK

RELATED WORK-Summary

Comparison with related work

Table 1: Information leakage management methods comparison

Method Description Context Advantage Downside Reference

Oblivious Cross-Tags(OXT)

Searchable symmetricencryption

Searches for a set of key-words

Practical (1)Multiple interactions;(2)Pre-Processing

Cash et al. [5]

Extended-OXT Searchable symmetricencryption

Searches for a set of key-words

Extends OXT (1)Sub-string; (2)Wild-cards,Phrase

(1)Multiple interac-tions;(2)Preprocessing

Faber et al. [6]

CryptDB Secure query processing SQL aware database Efficient Leakage from encrypteddata

Popa et al. [2]

SecureNoSQL Leakage resilient queryprocessing over en-crypted database

NoSQL database Covers: (1)searchover encrypted NoSQLdatabases; (2)Leakageprevention

Requires extra resourcefor Proxy

Current work *

* The extended version of this paper is ready publish.

JSON And BSON

JSON And BSON:Open standard format

Self describing format

BSON is a binary extension for JSON

BSON supports more data types

In this work we use JSON to create a new concept called security plan.

JSON And BSON

SecureNoSQL

We deign SecureNoSQL that provides practical and provable confidentiality in presenceof threats for applications backed by NoSQL databases.

The key part of SecureNoSQL is evaluation a set of operations on the encrypteddatabases. Moreover, the designed novel algorithms for information leakage preventionfrom data or query are added to SecureNoSQL.

We introduced a novel descriptive language based on the JSON notations which enablesthe users to generate a security plan. The security plan is useful tools for data owners forregulating security parameters management without getting involved in the details.

SecureNoSQL

Architecture

Figure 1: High-level architecture of SecureNoSQL as a secure proxy between user’s applications and cloud NoSQLdatabase server.Mohammad Ahmadian (UCF) Secure NoSQL April 9, 2017 22 / 42

More features of SecureNoSQL

1 Descriptive language based on JSONnotations to create a security plan.

2 A multi-key, multi-level mechanism.

3 The effective validation procedure againstsecurity plan in SecureNoSQL helps toavoid unnecessarily increase of workloadand response time of remote cloud server.

4 Support for a comprehensive, flexibleprotection. The solution is open-ended,users can add new customizedcryptographic modules simply by usingdesigned descriptive language.

5 A balanced system with a securitylevel-proportional overhead. The overheadof scheme is proportional to the desiredlevel of security.

6 SecureNoSQL addresses the informationleakage from fully or partially encrypteddatabases in the cloud. a

aThe malicious insider could pool all databases andextract sensitive information from correlation withvarious hosted databases.

Super Document

Super Document:

d1 =⟨〈k1, v1〉, 〈k2, v2〉, . . . , 〈ki , vi 〉

⟩d2 =

⟨〈k1, v1〉, 〈k2, v2〉, . . . , 〈kj , vj〉

⟩. . .

dn =⟨〈k1, v1〉, 〈k2, v2〉, . . . , 〈kl , vl〉

⟩Super Document D =

n⋃i=1

Match function : M(di , dj) determines whether any two given documents di , dj can bemerged or not.5

5Two documents can be merged provided that they share the same attribute from an identifying class orgroup of attributes from semi-identity class.

Security Plan

Security plan is a document contains a hierarchical collection of key-value pairs that describesdata elements, parameters of cryptosystems and mapping between these two. Every securityplan document includes four top-level sections represented in key-value pairs.

Figure 2: The high level structure of the security plan.

Security Plan-Collection

Figure 3: Collection (metadata) encryption:(a) The chart outlines the structure of collection containing the name ofcollection and name of all fields which are considered as meta-data thus should be protected with proper cryptographicmodule. The pointer to a crypto-module, the encryption key, and the initialization vector used for the encryption of theitems. (b) The description of a collection and security parameters in designed JSON based language.

Security Plan-Cryptographic Modules

Cryptographic modules introduces allcryptosystems and their parameters such askey, key-size, initialization vector andoutput-size.

Figure 4: Cryptographic Modules

Security Plan-Data Elements

Figure 5: Data elements containing attributes of data elements such as name, type and value for of collection and name.Then introduces security parameters for each data elements. (b) The data element section of a sample database whichare represented in designed notation. A data item has 7 fields: id, name, salary, balance, ccn, ssn, and email. The id,name, email and salary are required fields.

Security Plan-Mapping Cryptographic Modules to The Data Field

Figure 6: Structure and description of Mapping cryptographic modules to the Data element: (a) Security plan with thefourth section expanded. This section establishes a correspondence between the data fields and the cryptographic modulesused to encrypt and decrypt it. (b) The mapping section of the schema for a sample database with 7 fields. For example,the id and the name will be encrypted with OPE 128 bit and AES-DET, respectively.

Security Plan-KVP And Document Data Models

Figure 7: SecureNoSQL applied to: (a) The key-value data model; Key1, . . . ,Keyn are all encrypted using thecryptographic module z while the corresponding values, Value1, . . . ,Valuen are encrypted with cryptographic modules1, 2, . . . , n, respectively. (b) The document store data model; the meta-data such as collection name encrypted as well asattributes with assigned cryptographic modules.

Security Plan-Query and data validation

Figure 8: The validation process of input data against security plan in the client side.

An Example

Figure 9: Security plan designed for sample input: (a) Data element section of sample security plan. (b) Output of JSONData validation for sample database.

Query Encryption

Figure 10: The query db.customers.find({salary:{$gt:5000}, balance:{$lt:2000}}) received from an application. (a) Theparsing tree of the query (b) The cryptographic modules applied to the data elements according to schema definition

Example Queries

Table 2: Sample queries and their corresponding encrypted version

Query Encrypted query

1 db.customers.find({ssn:936136916})db[”k/IevnbanDMQHNkb9cRgUg==”].find({”5pgAxn6BF08WtM7zyu

YaKg==”:74172405478441908041711118833862143778})

db.customers.find({balance:{$gte:

5084610},balance:{$lte:9911843}})

db[”k/IevnbanDMQHNkb9cRgUg==”].find({”3iXpo2l8xZpW7J7TezFde

A==”:{$gte:402982988013604629517872370128473753},”3iXpo21

8xZpW7J7TezFdeA==”{$lte:7855963556987175927802686333694542

db.customers.aggregate([{$group:{ id

:null,minBalance:{$min:”$balance”}}}])db[”k/IevnbanDMQHNkb9cRgUg==”].aggregate([{$group:{ id:

null,EncMinBalance:{$min:”$3iXpo2l8xZpW7J7TezFdeA==”}}}])

db.customers.aggregate([{$group:{ id:

null,maxBalance:{$max:”$balance”}}}])db[”k/IevnbanDMQHNkb9cRgUg==”].aggregate([{$group:{ id:null

,EncmaxBalance:{$max:”$3iXpo2l8xZpW7J7TezFdeA==” }}}])

db.customers.find({$or:[{Salary:{$gt:

516046}},{balance:{$lt:285462}}]})

db[”k/IevnbanDMQHNkb9cRgUg==”].find({ $or: [ { ”9mnGu8Q2V

DstE+T9jFw2wQ==”: { $gt: 40994186216785746613193244129885849

}},{”3iXpo2l8xZpW7J7TezFdeA==”:{$lt:226574304531446346797

91167652174833}}]})

Overhead Data

Table 3: Overhead of encryption upon security level

Database Plain OPE64 OPE128 OPE256 OPE512

Size(MB) 170 430 508 662 1000

Table 4: Overhead of RND and DET encryption

Database Plain RND DET

Size(MB) 170 170 170

Table 5: Overhead of AHOM encryption

Database Plain AHOM

Size(MB) 170 10880

Measurements & experiments results

Figure 11: Query processing time in milliseconds (ms) for the unencrypted database and for the encrypted databases whenthe 32-bit keys are encrypted as 64, 128, 256 and 512-bit integers.

Measurements & experiments results

Response time: shortest for comparison and longest for aggregated queries.

The query processing time: for a given type of query increases, but only slightly, less than5% when the key length increases from 64, to 128, 256, and 512 bit.As expected, the OPE encryption time increases significantly with the size of the encryptionspace; it increases almost tenfold when the size of the encrypted output increases from 64-bitto 1024-bit and it is about 10 ms for 256-bit.

The decryption time is considerably smaller, it increases only slightly from 0.11 ms to 0.17when the size of the encrypted key increases from 64-bit to 1024 bit.

Future work

The current research will be continued by the following suggestions:

Multiple proxies in order to deal with a huge number of clients,

Developing an efficient, fully homomorphic encryption for unlimited operations over theencrypted data,

Encryption key management mechanism development for periodically assigning new keyfor cryptosystems in order to obtain higher levels of security.

References I

P. Paillier, “Public-key cryptosystems based on composite degree residuosity classes,” inAdvances in cryptologyEUROCRYPT99. Springer, 1999, pp. 223–238.

R. A. Popa, C. M. S. Redfield, N. Zeldovich, and H. Balakrishnan, “Cryptdb: Protectingconfidentiality with encrypted query processing,” Proc. of the Twenty-Third ACMSymposium on Operating Systems Principles, pp. 85–100, 2011.

D. Cash, J. Jaeger, S. Jarecki, C. Jutla, H. Krawczyk, M.-C. Rosu, and M. Steiner,“Dynamic searchable encryption in very-large databases: Data structures andimplementation,” Network and Distributed System Security Symposium (NDSS14), 2014.

M. Ahmadian, F. Plochan, Z. Roessler, and D. C. Marinescu, “SecureNoSQL: Anapproach for secure search of encrypted nosql databases in the public cloud,” InternationalJournal of Information Management, vol. 37, no. 2, pp. 63 – 74, 2017. [Online]. Available:http://www.sciencedirect.com/science/article/pii/S0268401216302262

References II

D. Cash, S. Jarecki, C. Jutla, H. Krawczyk, M.-C. Rosu, and M. Steiner, “Highly-scalablesearchable symmetric encryption with support for boolean queries,” in Advances inCryptology–CRYPTO 2013. Springer, 2013, pp. 353–373.

S. Faber, S. Jarecki, H. Krawczyk, Q. Nguyen, M. Rosu, and M. Steiner, “Rich queries onencrypted data: Beyond exact matches,” in European Symposium on Research inComputer Security. Springer, 2015, pp. 123–145.

The End

QuestionsDownload slides here:

SECURE QUERY PROCESSING in CLOUD NoSQLcs.ucf.edu/~ahmadian/pubs/ICCE2017 Presentation.pdf ·...

Documents

Transcript of SECURE QUERY PROCESSING in CLOUD NoSQLcs.ucf.edu/~ahmadian/pubs/ICCE2017 Presentation.pdf ·...