Release-aware In-out Encryption Adjustment in MongoDB Query

Processing

Maryam Almarwani, Boris Konev and Alexei Lisitsa

Department of Computer Science, University of Liverpool, Liverpool, U.K.

Keywords:

Querying Over Encrypted Data, Document Database, CryptDB.

Abstract:

Querying over encrypted data typically uses multi-layered (onion) encryption, which requires level adjustment

when processing queries. Previous studies, such as on CryptDB, emphasize the importance of inward encryp-

tion adjustment, from outer layers to inner layers, releasing information necessary for query execution. Even

though the idea of outward encryption adjustment, which is used to re-establish the outer layers after query

processing, is very natural and appeared already in the early papers on CryptDB as a topic for future work, no

prior studies have addressed it systematically. This paper extends previous work on intelligent, release-aware

encryption adjustment for document-based databases querying with the outward adjustment policy. We deﬁne

the resulting Release-Aware In-Out Encryption Adjustment principles and report on their empirical evaluation

using both local and cloud deployment of MongoDB. The evaluation utilizing datasets of different sizes shows

that the proposed method is efﬁcient, scalable, and provides better data protection.

1 INTRODUCTION

To keep data protected, it is usually stored in an en-

crypted form, and it needs to be decrypted before

processing or querying. Decryption, however, could

make the data vulnerable to server-side attacks. To

mitigate the issue, querying over encrypted data has

been proposed, in which multi-layered (onion) en-

cryption is commonly used. Multiple layers pro-

tect information and, at the same time, may release

some partial information on the data depending on

the types of encryption used at different layers. Con-

sequently, a reasonable encryption adjustment policy

is needed, which given a query, leads to decryption

of some layers to reveal the information sufﬁcient for

the query execution. Such a scheme was ﬁrst pro-

posed for relational databases and SQL querying in

a well-known work on CryptDB (Popa et al., 2011)

and then was transferred further to other types of

databases and query languages/APIs, see e.g. (Abu-

rawi et al., 2018b) for graph databases, (Xu et al.,

2017),(Almarwani. et al., 2019),(Almarwani et al.,

2020a) for document databases, and (Shih and Chang,

2017),(Waage and Wiese, 2017),(Wiese et al., 2020)

for wide-column database. As it has been already no-

ticed in (Popa et al., 2011) a simple encryption adjust-

ment policy (SEA) may lead to an unnecessary revela-

tion of more information about the data than required

for the query execution. To alleviate the issue to

some extent, a new Join-aware encryption adjustment

(JAEA) schema for relational databases was proposed

in (Popa et al., 2011). Similarly, traversal-aware

schema (TAEA) for graph databases and release-

aware schema (RAEA) for document databases were

proposed in (Aburawi et al., 2018a) and (Almarwani

et al., 2020b), respectively. These schemata turned

out to be more secure than variants of SEA by releas-

ing less information when executing JOIN, traversal,

and conjunctive/disjunctive queries, respectively.

The main focus of the above-mentioned adjust-

ment technologies was in applying decryption to the

layers from outer to inner, releasing more informa-

tion about the data and making the data less secure.

Far less attention was paid to the question of what

to do after the query has been completed and data

protected by the inner layers remain less secure. In

the original paper on CryptDB (Popa et al., 2011),

a very natural approach was outlined – to re-encrypt

the data to the original levels of encryption and re-

store protection, but an elaboration of the details was

left to future work. The development of encryption

adjustment techniques has shown that the details are

important here, as adopting different policies would

likely affect both efﬁciency and security. To the best

of our knowledge, these type of questions has not

been addressed systematically by the previous stud-

714

Almarwani, M., Konev, B. and Lisitsa, A.

Release-aware In-out Encryption Adjustment in MongoDB Query Processing.

DOI: 10.5220/0010395007140722

In Proceedings of the 7th International Conference on Information Systems Security and Privacy (ICISSP 2021), pages 714-722

ISBN: 978-989-758-491-6

ies. In this paper, we address the questions of in-

ward and outward adjustment for querying encrypted

document databases and introduce Release-Aware In-

Out (RAIO) Encryption Adjustment. This is an ex-

tension of the RAEA policy we proposed early for in-

ward adjustment in (Almarwani et al., 2020b). We de-

velop RAIO for NoSQL document-based MongoDB

databases. NoSQL databases become very popular

in recent years to handle large amounts of unstruc-

tured data, and MongoDB is the most popular NoSQL

database according to the ranking in The contribu-

tions of this paper can be summarized as follows:

• We propose an outward adjustment procedure, an

additional phase after processing queries to re-

store the outer encryption layers that were ad-

justed before processing. Both phases constitute

a novel RAIO policy.

• We analyse the security and incurred overhead of

our new policy compared to the original policy.

• We report on the empirical evaluation of the scala-

bility of our policy in comparison with the original

policy.

• We provide an assessment of the performance of

our policy on MongoDB deployed locally and on

the cloud from three cloud service providers.

This paper is organized as follows. Section II gives a

brief overview of multi-layer encryption and the Mon-

goDB API. A Release-aware In-Out Encryption Ad-

justment is introduced in Section III. Our experiments

and results are reported in Section IV. Section V sum-

marizes relevant work. Our conclusions and future

work are drawn in the ﬁnal section.

2 BACKGROUND

2.1 Multi-layered Encryption

Multi-layered, or onion encryption is a fundamental

concept used in the implementation of querying over

encrypted data since the inﬂuential paper on CryptDB

(Popa et al., 2011). The idea is simple and powerful.

Each data element is encrypted by several layers of

encryption of different types. Full data protection can

be achieved by using a random layer of encryption

(RND), which does not reveal any information about

encrypted data, not even equality. Deterministic layer

(DET) allows testing the equality between encrypted

values. More advanced functionality can be provided

by partially- or fully- homomorphic encryption (PHE,

or FHE), allowing to perform computations over en-

crypted data. Furthermore, order-preserving encryp-

tion (OPE) and searchable encryption allow cryp-

tographic numerical values to be compared and the

search carried out. Depending on what queries are

required, the data elements can be protected by dif-

ferent onions combining the layers of various types

of encryption. Executing a query over such protected

data may require encryption adjustment. For exam-

ple, if a query requires an equality check (e.g., salary

= 30.000) and the outer layer of encrypted salary val-

ues is RND and a layer immediately under it is DET,

then the outer layer has to be removed by decryption

before the query may proceed while still keeping data

protected at DET level. The query pre-processing,

the encryption adjustment, and post-processing of

encrypted results in CryptDB-like schemes are per-

formed by a proxy component placed between the

server and a client. Figure 1 outlines the correspond-

ing workﬂow. The proxy proceeds as follows: (i) it re-

ceives a query from an application/client and adjusts

data on the database (ii) rewrites the query by replac-

ing its explicit values/constants with their encrypted

versions and sends the resulting query to the database;

(iii) decrypts received results and sends them to the

user. The approach we propose in this paper is generic

and may work together with different types of encryp-

tion. However, for the validation and empirical evalu-

ation, we have implemented a research prototype us-

ing three types of encryption methods for built-in lay-

ers, including AC, DET, and OPE. Access Control

(AC)(Almarwani et al., 2020a) layer presents the val-

ues encrypted using Cipher-Policy Attributes-Based

Encryption (CP-ABE) (Bethencourt et al., 2007). AC

layer provides protection similar to RND (equal plain-

text values are very likely encrypted to different ci-

phertexts), and additionally, it enables the implemen-

tation of access policies that determine the users au-

thorized to access the data. AC, like RND, enables no

computational operations concerning the encrypted

value, while DET and OPE layers enable equality

and range computation, respectively. Each encryp-

tion type releases some information about encrypted

values, and the information inclusion induces a par-

tial order on the encryption types. For the encryption

types we use in this paper, this order is actually linear:

AC  DET  OPE  PLAIN, where PLAIN denotes

“no encryption”.

Figure 1: Workﬂow of Querying over Multi-layers Encryp-

tion data.

Release-aware In-out Encryption Adjustment in MongoDB Query Processing

715

2.2 MongoDB API

In this paper, we develop a new encryption adjustment

policy for querying encrypted document databases.

We present and evaluate the concept using MongoDB.

MongoDB data consist of collections, and each col-

lection includes a number of documents. Each doc-

ument is formed by ﬁelds and values. Unlike many

other types of databases, MongoDB doesn’t support

a particular query language. Instead, an Application

Program Interface (API) allows to manage MongoDB

documents programmatically. MongoDB API high-

level syntax is given below (Tutorial, 2017): To read

data from MongoDB, the ﬁnd() function is used. If

the Find-Criteria is empty, all documents in the col-

lection will be retrieved and returned. In contrast, if

the Find-Criteria is deﬁned, documents that only sat-

isfy certain criteria will be retrieved and returned. To

modify data the functions insert(), update(), delete()

are used.

Insert() function is to add a document to the collec-

tion; therefore, the Insert-Criteria no need operators

or conditions to do it.

Update() function is to update ﬁelds values in

Change-Criteria Parameter for fetched documents by

Update-Criteria.

Delete() function is to delete documents that match

the Delete-Criteria. Further details of the syntax and

semantics of the API can be found in (Tutorial, 2017).

3 ENCRYPTION ADJUSTMENT

POLICIES

To perform queries and updates on encrypted Mon-

goDB data, one should evaluate Conditions over such

data. According to MongoDB API BNF, Condi-

tions are boolean combinations of atomic Expres-

sions, which are build using comparison operators.

For a comparison operator op we denote by SL

the

minimal wrt to  encryption level (Support Level) of

the arguments of op sufﬁcient for evaluation of op

on these arguments. We have SL

= DET , while

= SL

≤

= SL

≥

= SL

= OPE. For a MongoDB

API query Q we denote by E(Q) the set of all atomic

expressions occurring in Q. For an atomic expression

(<Expression 1>) e we denote by op(e) the operator

occurring in e and by f ield(e) the ﬁeld name occur-

ring in e.

For a query Q and a ﬁeld name f occurring in Q

we deﬁne S

( f ) = max

{e∈E(Q)| field(e)= f }

op(e)

Notice that the same ﬁeld name f may occur in

different expressions, which may require a different

level of adjustment. Taking maximums (wrt to ) ad-

justment levels for all f as assumed in the deﬁnition

of S

( f ) makes it possible to evaluate all expressions

in E(Q) and execute Q over encrypted data store. For

a MongoDB database instance I and a ﬁeld f we de-

note by # f

the number of the documents in I contain-

ing the ﬁeld f .

3.1 Simple Encryption Adjustment

Simple Encryption Adjustment policy (SEA) follows

very simple principles. According to SEA, before an

execution of a query Q the encryption levels of all val-

ues of all ﬁelds f occurring in Q have to be adjusted

to the encryption levels S

( f ). The query Q itself has

to be rewritten into its “encrypted” version Q

∗

: all

plain values of all ﬁelds f in Q have to be replaced by

encrypted S

( f ) values.

Such deﬁned policy operates inwards - starting

with the maximum security level (or minimum wrt to

information release order ) it adjusts the encryption

to lower security (higher wrt ) levels for some data

elements ﬁelds.

SEA policy was ﬁrst proposed for relational

databases in (Popa et al., 2011) and its variant for

document-based DBs was considered in (Almarwani

et al., 2020a). SEA can be extended naturally to the

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

716

outward mode too: after SEA applied inwards, and a

query is executed, the encryption of all adjusted val-

ues has to be restored to the outer layer of maximal

security.

While SEA policy is easy to deﬁne and imple-

ment, it may incur large overhead for large databases

(too many data values have to be decrypted/re-

encrypted). It may reveal more information about

data elements than necessary for the query execution

(Popa et al., 2011). To alleviate such effects, (Almar-

wani et al., 2020b) proposed Release-Aware Encryp-

tion Adjustment (RAEA) policy, originally in inward

mode only.

3.2 Release-aware In-out Encryption

Adjustment

The Inward RAEA strategy releases less server-side

information than SEA by reducing the number of en-

cryption adjustments to the inner layer(s). This limits

the number of decryptions by 1) performing the ad-

justment not before but alongside the query execution

and 2) taking into account the number of occurrences

(’popularity’) of the various ﬁelds. We now describe

an Outward Adjustment extension of RAEA, which

we call the Release-Aware In-Out (RAIO) Encryption

Adjustment. The policy is deﬁned for both Conjunc-

tive Conditions and more general Disjunctive Normal

Form (DNF) conditions for the MongoDB API calls.

These Condition classes in the MongoDB API can be

deﬁned as follows:

RAIO encryption adjustment consists of two

parts. The ﬁrst part, Inward adjustment, expands The

Inward RAEA policy from (Almarwani et al., 2020b)

to the wider class of conditions. The second part, Out-

ward adjustment, is a newly proposed policy to deal

with the re-establishing protection of the data whose

encryption layers have been adjusted for querying.

(A) Release-Aware (Inward) Encryption Adjust-

ment(RAEA)

Find Queries. First, we consider the Conjunc-

tive Conditions case. A Find query Q in Mon-

goDB API has a form db.collection.find(C(Q)),

where for conjunctive queries C(Q) = e or C(Q) =

$And{e

, . . . , e

} and e and e

are atomic expressions.

For C(Q) = $And{e

, . . . , e

} and 1 ≤ k ≤ n we denote

$And{e

, . . . , e

} by C

(Q). For C(Q) and C

(Q) we

denote by C

∗

(Q) and C

∗

(Q) their encrypted variants

obtained by adjustments of constant values in all e

the encryption levels S

( f ield(e

)). Corresponding

queries will be denoted by Q

∗

and Q

∗

, respectively.

For a ﬁnd query Q and a database instance I we denote

by D(Q, I) the set of documents returned by execution

of Q on I.

Given a conjunctive query Q and a MongoDB

database instance I, RAEA adjustment and query ex-

ecution proceed as follows:

If C(Q) = e, then SAE policy is applied: all val-

ues of f ield(e) in I are adjusted to the encryption

level S

( f ield(e)). The query Q is encrypted to Q

∗

by adjusting the constant value in e to the same level

( f ield(e)). Then Q

∗

is executed.

If C(Q) = $And{e

, . . . , e

}, n ≥ 2

then popularity in I of all ﬁelds f occur-

ring in C(Q) is calculated by calling # f

db.collection.find($f$:{\$exist:true})

.count(); The original query condition C(Q) is

re-written by sorting atomic expressions accord-

ing to the popularity order, that is to C(Q

≤

) =

$And{e

, . . . , e

}, where # f ield(e

)

≤ # f ield(e

i+1

)

i = 1, . . . , n − 1. Then the following iterative steps are

executed. Let I

= I.

• All values of f ield(e

) in the whole I

are ad-

justed to the encryption level S

( f ield(e

)) re-

sulting in a database state I

;

• The values of f ield(e

) occurring in the docu-

ments D(Q

∗

≤

, I

) are adjusted to S

( f ield(e

))

resulting in I

;

• ···

• The values of f ield(e

) occurring in the doc-

uments from D(Q

∗

≤

i−1

, I

i−2

) are adjusted to

( f ield(e

)) resulting in I

;

• ···

These steps are completed either

• by the execution of the last possible Q

∗

≤

, that is

∗

≤

on I

n−1

with the result being the required (en-

crypted) result of the execution of the whole query

Q on encrypted instance I; or

• by a query Q

∗

≤

with k < i returning empty set of

documents.

In either case, n, respectively k are recorded

as stop points of the execution. This information

is needed for the procedure of outward adjustment

which should follow afterwards.

As the ﬁelds can be repeated in the query, we

assume that before an adjustment of any ﬁeld to be

done, it is checked whether it is already been done,

and if so, it is skipped.

The presented policy may reduce the number

of adjustments/re-encryptions compared with SEA,

since adjustments of the ﬁelds’ values are starting

Release-aware In-out Encryption Adjustment in MongoDB Query Processing

717

with the least popular ﬁelds and are performed on

gradually narrowing sets of documents. Consider an

example. Let Q be the following query:

db.collection.find($AND:{Name:$eq Alice,

Salary:$gt 9000, Salary:$lt 40000,Age:$lt

50,Age:$gt 25,Department:$eq Computer})Q1

Assuming #Salary

≤ #Age

≤ #Department

in an

instance I

we have C(Q

≤

) =

$AND:{Salary:\$gt 9000, Salary:\$lt 40000,

Age:\$lt 50,Age:\$gt 25,Name:\$eq Alice,

Department:\$eq Computer})

• As f ield(e

) = Salary all values of Salary in the

whole I

are adjusted to the encryption level OPE

resulting in I

• As f ield(e

) = Salary and the encryption level of

Salary values has already been adjusted we skip

its further adjustments.

• The values of Age = ﬁeld(e3) occurring in the doc-

uments D(Q

∗

≤

, I

), that is those matching e1

∗

∧

∗

, are adjusted to the encryption level OPE re-

sulting in I

;

• Skip further adjustments of Age = ﬁeld((e4) as it

has been already adjusted.

• The values of Name = ﬁeld(e5) occurring in

the documents D(Q

∗

≤

, I

), that is those matching

∗

∧ e2

∗

∧ e3

∗

∧ e4

∗

, are adjusted to the encryp-

tion level DET resulting in I

;

• The values of Department = ﬁeld(e6) occurring in

the documents D(Q

∗

≤

, I

), that is those matching

∗

∧ e2

∗

∧ e3

∗

∧ e4

∗

∧ e5

∗

, are adjusted to the en-

cryption level DET resulting in I

;

• Finally, assuming all previous partial queries did

not return empty set of the documents, we execute

≤

= Q

∗

≤

on I

and D(Q

∗

≤

, I

) is the (encrypted)

result of the execution of the original Q on the

encrypted instance I

Each time a new f is adjusted, the number of selected

documents is lower than that in the previous step, de-

spite the new f being no less/more popular in I. This

is because the increasing number of constraints e

∗

(Q) with growing k, leads to the reduction of the

numbers of the documents in D(Q

∗

≤

k−1

, I

k−2

) that are

more likely to satisfy Q.

Disjunctive Normal Form (DNF) Case. For a DNF

query Q we have C(Q) = $Or{c

, . . . c

}, where c

$And{e

, . . . , e

}. The processing of such a Q is done

by a separate processing of conjunctive queries with

conditions c

as explained above and taking the union

of the sets of the documents returned by these con-

junctive queries as the result. To ensure correctness

and efﬁciency, the information on already adjusted

ﬁelds is passed to the the processing of further con-

junctive sub-queries. In this case there are many op-

portunities for further optimizations and this is a sub-

ject of our ongoing work.

Write Query Processing. For the case of Update and

Delete queries, the proxy processes C(Q) using the

same steps as for a Read (Find) queries except there

is no need to receive and decrypt a result. For the

case of Insert queries, the proxy encrypts all inserted

values by layers to the maximum security level.

(B) Outward Encryption Adjustment(OEA)

Restoring the data values to the maximum security

level after executing queries reduces the amount

of information exposed to the database after query

processing. The main difﬁculty here is to ﬁnd out

which values have been adjusted to the lower levels.

We propose here the Outward Encryption Adjustment

(OEA) policy, which works on pair with inward

RAEA and allows to determine which values need to

be restored to the maximum security level without

disclosing more than necessary information to the

database.

Find Queries. First, we consider the Conjunctive

Conditions case. We assume that a query Q has al-

ready been processed using above RAEA policy. If

C(Q

∗

)=e

∗

then all values of f ield(e) in I are restored

to the maximum security level.

If Q

∗

≤

= $And{e

∗

, . . . , e

∗

}, where s is the stop point

of RAEA adjustment and s ≥ 2, then Q

∗

≤

is re-written

in reverse to sort atomic expressions descending to

the popularity order, that is to Q

∗

≥

=$And{e

∗

, . . . , e

∗

}, where # f ield(e

∗

})

≥ "#" f ield(e

∗

i−1

})

, i = s −

1, . . . , 1.

Then the following iterative steps are executed. Let

= I.

• The values of f ield(e

) occurring in the docu-

ments from D(Q

∗

≥

s−1

, I

) are restored to the maxi-

mum security level resulting in I

s−1

;

• ···

• The values of f ield(e

) occurring in the docu-

ments from D(Q

∗

≥

i−1

, I

s−i

) are restored to the max-

imum security level resulting in I

i−1

;

• ···

• All values of f ield(e

) in the whole I

are restored

to the maximum security level.

We illustrate the proposed outward adjustment

procedure by the following example.

Let C(Q

≤

) =

$AND:{Salary:\$gt 9000, Salary:\$lt 40000,

Age:\$lt 50,Age:\$gt 25,Name:\$eq Alice,

Department:\$eq Computer})

re-write C(Q

≥

) =

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

718

$AND:{Department:$eq Computer,

Name:$eq Alice,Age:$gt 25,Age:$lt 50,

Salary:$lt 40000,Salary:\$gt 9000})

where #Department(e6) ≥ #Name(e5) ≥

#Age(e4) ≥ #Age(e3) ≥ #Salary(e2) ≥ #Salary(e1).

• The values of Department = ﬁeld(e6) occurring

in the documents D(Q

∗

≤

, I

), which are match-

ing e5

∗

∧ e4

∗

∧ e3

∗

∧ e2

∗

∧ e1

∗

, are restored to the

maximum security level resulting in I

;

• The values of Name = ﬁeld(e5) occurring in the

documents D(Q

∗

≤

, I

), which are matching e4

∗

∧

∗

∧ e2

∗

∧ e1

∗

, are restored to the maximum se-

curity level resulting in I

;

• Skip Age(e4) that is repeated ﬁeld and not been

restored yet.

• The values of Age = ﬁeld(e3) occurring in the doc-

uments D(Q

∗

≤

, I

), which are matching e2

∗

∧e1

∗

are restored to the maximum security level result-

ing in I

;

• Skip Salary = ﬁeld(e2) that is repeated ﬁeld and

not been restored yet.

• All values of Salary = ﬁeld(e1) in the whole I

are

restored to the maximum security level.

The case of outward adjustment for Disjunctive

Normal Form (DNF) conditions is dealt with simi-

larly to the case of inward adjustment: each of the

conjunctive components is processed separately.

Write Queries. Here, the Insert query does not need

any action in OEA while the Delete query follows the

same steps as for a Find query. Whereas, for Update

query, if at least one of the ﬁeld in the change-criteria

is present in the Update-criteria, updated documents

must be processed to restore values to the maximum

security level because these documents do not meet

the update-criteria. Then, the steps for Find query us-

ing update-criteria are followed for non-updated doc-

uments.

This section presents a case study and compares the

SEA and RAIO applied to the same small database

instance. Figure 3 presents a sample of the document

database with nine documents, each containing up to

four ﬁelds with a total of 29 values, as shown in Fig-

ure 2 in the left part. The data is encrypted with

one onion by using three algorithms(CP-ABE(AC),

AES(DET), Order-preserving Encrypted(OPE)), as

shown in Figure 2 in the right part. Q3 is an exam-

ple of the query which is executed over encrypted data

using inward and outward encryption adjustments fol-

lowing two policies, SEA, and RAIO. Therefore, it is

noticed that all values (i.e. 29) in E(Q) are adjusted

in IEA and are restored in OEA for SEA, as shown

Figure 2: Case study sample data.

Figure 3: Inward Encryption Adjustment.

Figure 4: Outward Encryption Adjustment.

in bold red in Figure 3, 4 in the right part. In con-

trast, selected values (i.e. 16) are adjusted in IEA and

are restored in OEA for the RAIO case’s, as shown in

bold red in Figures 3, 4 in the left part. Therefore for

this case RAIO provides better than SEA protection

of the data, as fewer values are exposed at the lower

protection levels.

$db.collection.find({$or:$and:{Name:$eq

"Anthony",Salary:$gt 9000}], $and:

{Department:$eq"Quality Assurance",

$ID:$eq:"02CADED4"}]}); Q3

4 EVALUATION

The evaluation of RAIO policy was carried out us-

ing a workﬂow from Figure 1 extended by Data

Owner entity. The scheme contains four entities: Data

Owner, User, Proxy, and Database. The data owner

encrypts and uploads data to the database, while the

proxy is responsible for handling queries over en-

crypted data between the database and the user.

Experiments Setup. Three layers of data en-

cryption were used, CP-ABE(Bethencourt et al.,

2007), AES(Halevi and Rogaway, 2003), and

OPE(Boldyreva et al., 2011), with code derived from,

respectively, (Wang, ),(Kamble, ), and (Savvides, ).

This implementation was based on Java 8 and Net-

Beans 8.2 . The experiments were conducted using a

desktop PC running Windows 10 with an Intel Core

Release-aware In-out Encryption Adjustment in MongoDB Query Processing

719

Table 1: Test Queries.

Q Criteria Fields Query Fields Change

Find Conj. First-name,Salary -

Find DNF First-name,Salary,Department,City -

Update Conj. First-name,Salary Salary,City

Update DNF First-name,Salary, Department,City Salary,City,Department

Delete Conj. First-name,Salary -

Delete DNF First-name,Salary,Department,City -

1.8 GHz processor and 8.00 GB of RAM. A doc-

ument can include First-Name, Last-Name, Credit-

Card-Number, Salary, Department, Country, and City

ﬁelds. Document data was generated using the API

Mocking tool. For all experiments, user, data owner,

and proxy were run in the local environment. In con-

trast, MongoDB was run either as Local, on the Mon-

goDB community, or in the Cloud, using three differ-

ent cloud providers, Amazon Web Services (AWS),

Microsoft Azure, and Google Cloud Platform (GCP).

Experiments Design. The main objective of the ex-

periments conducted is to test the RAIO’s efﬁciency

as compared to SAE. We have carried out two types of

experiments using different storage providers and dif-

ferent sizes of datasets. Conjunctive and Disjunctive

Normal Form (DNF) queries were chosen for experi-

ments with Find, Update and Delete operations. The

experimental query’s speciﬁcs are shown in the table

1. Each query ran 30 times, and the user, proxy, and

database entities were evaluated for their average exe-

cution times. User time is calculated between issuing

the query and the retrieval of results or executing data

changes to update and delete queries. The proxy time,

on the other hand, is the sum of the IEA and OEA

time, plus the database communication time, which is

the time needed for data to be retrieved, changed, or

removed, and the result’s decryption time. The ﬁrst

experiment measured the scalability of the proposed

approach to query processing, and it involved increas-

ing the number of database documents (1,000, 5,000,

and 10,000 documents). In the second experiment the

performance of RAIO was also tested for MongoDB

deployed in the cloud. The second experiment calcu-

lated the proposed approach’s execution time for three

cloud providers supporting MongoDB and compared

it to the local MongoDB’s execution time.

Results. In Table 2, the mean execution time for

various stages of processing for both RAIO and SEA

(Experiment 1) is shown. According to these results

RAIO policy consistently outperforms SEA. While

IEA and OEA times appear to grow linearly in the

size of the databases for both policies, in all cases

the time taken for these stages by RAIO is consid-

erably less than by SAE. The difference is even more

dramatic for Network-Delay stage. For simple pol-

icy the growth of Network-Delay time is superlinear,

while for RAIO it is still close to be linear, and for

Figure 5: Experiment 1 Result.

databases of size 10000 Network-Delay time is ˜ 2-3

times less for RAIO. There is no signiﬁcant differ-

ence in Result times, as this is for decryption of the

results of the query, and the number of result values is

the same, no matter under which policy a query is ex-

ecuted. We notice that Network-Delays(ND) have a

considerable effect on total proxy time and user time

due to the need for round-trip connections for adjust-

ment between the DB and proxy. Table 3 displays

the average times obtained for Experiment 2. Fig-

ure 6 displays the details of the average execution

time for local MongoDB vs. cloud providers. Exper-

iment 2 revealed, as predicted that the ND time has a

signiﬁcant effect on execution time due to the round-

trip connection. Due to Internet speeds or the perfor-

mance of the service services, an increase in time on

the cloud could also have been incurred.

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

720

Table 2: Comparison of Simple and Release-Aware In-Out Encryption Adjustment on Local MongoDB Community.

Q Criteria

RAIO (ms) SEA (ms)

User

Proxy

User

Proxy

IEA Result OEA ND IEA Result OEA ND

Thousand

Find

Conj. 2784 165 2.13 56 5398.13 4145 321 2.66 200 7398.13

DNF 4086.40 482.40 2.74 209.67 7471.60 6987.50 694.20 2.12 474.01 9914.90

Update

Conj. 825.87 201.27 0.67 177.40 266.6 1236.74 436.75 1.74 321.90 4365.10

DNF 2901.33 403.93 3.67 227 7671.6 4648.95 631.88 3.05 432.10 9748.70

Delete

Conj. 961.73 262.13 0 149.80 1612.67 1745.21 410.75 0 394.30 2745.97

DNF 2734.20 842.67 0 223.20 4455.33 4745.10 696.75 0 531.30 6745.12

Five-Thousand

Find

Conj. 4784 277 2.45 156 6398.13 8364 662 2.01 419 14826.27

DNF 6074.70 671.20 2.15 409.67 8471.60 14031 1411.40 2.33 982.02 19874.80

Update

Conj. 1025.15 422.75 1.14 274.70 4745.80 2529.48 907.49 1.45 737.80 8827.20

DNF 4784.12 611.75 3.79 474 9745.10 9320.90 1275.75 3.80 864.20 19573.40

Delete

Conj. 1171.79 474.24 0 214.10 3745.12 3502.42 877.49 0 809.60 5588.94

DNF 4741.80 674.75 0 497.80 6954.78 9557.20 1464.49 0 1094.60 13531.24

Ten-Thousand

Find

Conj. 5412 474 2.95 278 7745.12 16760 1398 2.14 892 29695.53

DNF 7748.90 874.90 2.89 614.78 10963.20 28076 2920.8 2.24 1976.05 39794.60

Update

Conj. 1230.75 674.75 1.80 441.20 6741.90 5068.96 1837.98 1.97 1529.60 177752.4

DNF 6741.32 811.44 3.33 601 11964.20 18706.80 2596.50 3.10 1815.40 39180.80

Delete

Conj. 3174.91 647.03 0 432.50 5745.12 7038.84 1766.98 0 1503.60 11275.88

DNF 6397.7 874.91 0 641.90 8012.98 19126.40 2995.98 0 2200.20 27085.48

Figure 6: Experiment 2 Result.

Table 3: Comparison of Release-Aware In-Out Encryption

Adjustment on Local MongoDB Community vs. Clouds

Providers.

Q Criteria

RAIO (ms)

User

Proxy

IEA Result OEA ND

Local

Find

Conj. 2784 165 2.133 56 5398.13

DNF 4086.4 482.4 2.73 209.67 7471.60

Update

Conj. 825.87 201.27 0.67 177.40 2662.60

DNF 2901.33 403.93 3.67 227 7671.60

Delete

Conj. 961.73 262.13 0 149.80 1612.67

DNF 2737.20 482.67 0 223.20 4455.33

Azure

Find

Conj. 10864.53 183.27 2.87 65.53 15530.87

DNF 15255.13 483.33 3.73 215.73 35430.13

Update

Conj. 13316.87 244.40 1.72 139.27 28419.07

DNF 10673 417.20 3.27 214.80 20666.80

Delete

Conj. 17301.07 275.60 0 151.40 71060.87

DNF 44357.93 481 0 238.47 82342.33

AWS

Find

Conj. 8592.13 184.73 2.73 60.47 16031.73

DNF 17975.73 497.53 3.47 216.80 38353.53

Update

Conj. 16405.10 261.13 1.07 185 26065.53

DNF 10988.13 458.40 3.20 256 20707.80

Delete

Conj. 40155.2 261.87 0 141.60 70170.13

DNF 55.30.20 480.13 0 220.33 80167.20

GCP

Find

Conj. 10223.87 185.33 2.87 63.20 16467.03

DNF 20400.73 459.20 3.53 214 45010.67

Update

Conj. 10125.33 208.47 1.13 145.07 16231.52

DNF 14469.20 408.47 3.33 245.07 26311.47

Delete

Conj. 55906.07 296.60 0 153.73 81041.53

DNF 47901 484.33 0 224.20 86517.07

5 RELATED WORK

CryptDB (Popa et al., 2011) was the ﬁrst to suggest

multi-layer encryption, encrypting each data element

into one or more onions, with onion layers represent-

ing increasingly stronger encryption. CryptDB is a

secure system for relational databases related to SQL

queries over encrypted data, and it uses SEA. Crypt-

MDB (Xu et al., 2017) is an efﬁcient encryption sys-

tem on MongoDB that uses a single additional crypto-

graphic asymmetric encryption system encrypt data,

thus performing only one additional operation, with

no need for adjustment of techniques. SDDB (Almar-

wani et al., 2020a), CryptGraphDB (Aburawi et al.,

2018b), and PPE schemes on WCSs (Waage and

Wiese, 2017) apply the concept of CryptDB transfer

to document databases (MongoDB), graph databases

(Neo4j database), and Wide-column databases (Cas-

sandra) respectively to execute queries on encrypted

data through SEA. In (Shih and Chang, 2017) and

(Wiese et al., 2020), CryptDB is moved to a wide

column store; Crypt-NoSQL uses multiple proxies to

distribute overhead; and CloudDBGuard removes the

proxy functions to the client-side. (Aburawi et al.,

2018a) proposes a traversal-aware encryption adjust-

ment synchronized with query execution, thus im-

proving security for the Simple technique on a Graph

database.

Release-aware In-out Encryption Adjustment in MongoDB Query Processing

721

6 CONCLUSION

This work introduced a Release-Aware In-Out en-

cryption adjustment, expanding on previous work

on Release-Aware Encryption Adjustment to improve

performance by dynamically adjusting selective ﬁelds

during query processing. Compared to SEA, RAIO

reduces overhead in decryption costs and provides

more security by exposing less information to the

database servers. The proposal also supports back-

ward adjustment to provide protection post query pro-

cessing. RAIO can also be extended to outsourced

databases such as cloud database providers. Our

proposal overhead is most signiﬁcantly affected by

exchange communication between the database and

proxy caused by MongoDB’s lack of support for

UDF. Future work includes extending the proposed

policy to the larger classes of queries and further opti-

mization, including reduction of communication cost

and execution time. We intend to reﬁne our policy’s

query behavior; we expect to use recent advances in

cryptographic algorithms and ﬁnd the best trade-off

between protection and efﬁciency to integrate them

into our future work policy.

REFERENCES

Aburawi, N., Coenen, F., and Lisitsa, A. (2018a). Traversal-

aware encryption adjustment for graph databases. In

DATA, pages 381–387.

Aburawi, N., Lisitsa, A., and Coenen, F. (2018b). Querying

encrypted graph databases. In Proceedings of the 4th

International Conference on Information Systems Se-

curity and Privacy, ICISSP 2018, Funchal, Madeira -

Portugal, January 22-24, 2018., pages 447–451.

Almarwani., M., Konev., B., and Lisitsa., A. (2019). Flex-

ible access control and conﬁdentiality over encrypted

data for document-based database. In Proceedings of

the 5th International Conference on Information Sys-

tems Security and Privacy - Volume 1: ICISSP,, pages

606–614. INSTICC, SciTePress.

Almarwani, M., Konev, B., and Lisitsa, A. (2020a). Fine-

Grained Access Control for Querying Over Encrypted

Document-Oriented Database, pages 403–425.

Almarwani, M., Konev, B., and Lisitsa, A. (2020b).

Release-aware encryption adjustment query process-

ing for document database. In Proceedings of the 2020

4th International Conference on Cloud and Big Data

Computing, pages 48–51.

Bethencourt, J., Sahai, A., and Waters, B. (2007).

Ciphertext-policy attribute-based encryption. In Secu-

rity and Privacy, 2007. SP’07. IEEE Symposium on,

pages 321–334. IEEE.

Boldyreva, A., Chenette, N., and O’Neill, A. (2011). Order-

preserving encryption revisited: Improved security

analysis and alternative solutions. In Annual Cryp-

tology Conference, pages 578–595. Springer.

Halevi, S. and Rogaway, P. (2003). A tweakable encipher-

ing mode. In Annual International Cryptology Con-

ference, pages 482–499. Springer.

Kamble, A. Basic aes and des implementation in

java. https://github.com/AjitTK/JAVAEncryption. Ac-

cessed: 2020-9-1.

Popa, R. A., Redﬁeld, C., Zeldovich, N., and Balakrish-

nan, H. (2011). Cryptdb: protecting conﬁdentiality

with encrypted query processing. In Proceedings of

the Twenty-Third ACM Symposium on Operating Sys-

tems Principles, pages 85–100. ACM.

Savvides, S. Order-preserving encryption in java. https:

//github.com/ssavvides/jope. Accessed: 2020-9-11.

Shih, M.-H. and Chang, J. M. (2017). Design and analysis

of high performance crypt-nosql. In 2017 IEEE Con-

ference on Dependable and Secure Computing, pages

52–59. IEEE.

Tutorial, A. (2017). Mongodb - java - tutorialspoint.

Waage, T. and Wiese, L. (2017). Property preserving en-

cryption in nosql wide column stores. In OTM Con-

federated International Conferences” On the Move to

Meaningful Internet Systems”, pages 3–21. Springer.

Wang, J. Java realization for ciphertext-policy attribute-

based encryption. https://github.com/junwei-wang/

cpabe. Accessed: 2020-9-1.

Wiese, L., Waage, T., and Brenner, M. (2020). Cloud-

dbguard: A framework for encrypted data storage in

nosql wide column stores. Data & Knowledge Engi-

neering, 126:101732.

Xu, G., Ren, Y., Li, H., Liu, D., Dai, Y., and Yang, K.

(2017). Cryptmdb: A practical encrypted mongodb

over big data. In Communications (ICC), 2017 IEEE

International Conference on, pages 1–6. IEEE.

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

722