Cryptographic Enforcement of Access Control Policies in the Cloud:

Implementation and Experimental Assessment

Stefano Berlato

1,2

, Roberto Carbone

and Silvio Ranise

2,3

DIBRIS, University of Genoa, Genoa, Italy

Security and Trust Research Unit, Fondazione Bruno Kessler, Trento, Italy

Department of Mathematics, University of Trento, Trento, Italy

Keywords:

Cryptographic Access Control, Experimental Assessment, Honest but Curious Cloud Service Provider.

Abstract:

While organisations move their infrastructure to the cloud, honest but curious Cloud Service Providers (CSPs)

threaten the conﬁdentiality of cloud-hosted data. In this context, many researchers proposed Cryptographic

Access Control (CAC) schemes to support data sharing among users while preventing CSPs from accessing

sensitive data. However, the majority of these schemes focuses on high-level features only and cannot adapt to

the multiple requirements arising in different scenarios. Moreover, (almost) no CAC scheme implementation

is available for enforcement of authorisation policies in the cloud, and performance evaluation is often over-

looked. To ﬁll this gap, we propose the toolchain COERCIVE, short for CryptOgraphy killEd (the honest but)

cuRious Cloud servIce proVidEr, which is composed of two tools: TradeOffBoard and CryptoAC. TradeOff-

Board assists organisations in identifying the optimal CAC architecture for their scenario. CryptoAC enforces

authorisation policies in the cloud by deploying the architecture selected with TradeOffBoard. In this paper,

we describe the implementation of CryptoAC and conduct a thorough performance evaluation to demonstrate

its scalability and efﬁciency with synthetic benchmarks.

1 INTRODUCTION

Cryptographic Access Control (CAC) allows organ-

isations to enforce Access Control (AC) policies

over cloud-hosted sensitive data while guaranteeing

strong conﬁdentiality, i.e., neither external attackers

nor Cloud Service Providers (CSPs) can read the

data. Several researchers proposed CAC schemes us-

ing different cryptographic primitives, like Attribute-

Based Encryption (ABE) (Jang-Jaccard, 2018), hy-

brid cryptography (Garrison et al., 2016), proxy re-

encryption (Rezaeibagha and Mu, 2016) and onion

encryption (Qi and Zheng, 2019).

While attaining remarkable qualities on paper, the

majority of these CAC schemes seldom considers a

concrete use in a speciﬁc scenario. As the focus is

usually on high-level features only, little space is left

for those aspects (e.g., ﬂexibility, portability) related

to CAC scheme deployments. In particular, the ar-

chitecture (i.e., the deﬁnition of the entities that com-

pose a scheme along with their logical or physical

locations) is usually not provided, or it is ﬁxed and

cannot accommodate the requirements (e.g., enhance

architecture scalability or minimize the vendor lock-

in effect) of different scenarios. Moreover, few re-

searchers provided even a prototype implementing

their scheme, often just for measuring the perfor-

mance of read and write operations on data. Finally,

such prototypes usually can interact with one CSP

only (e.g., Amazon Web Services (AWS), Google

Cloud Platform (GCP) or Azure). In other words,

there is a gap between CAC schemes in the abstract

and a concrete approach for real-world deployment.

To ﬁll this gap, we propose the toolchain

COERCIVE—open-source and available online

—

which is composed of two tools for achieving opti-

mal enforcement of role-based CAC policies in the

cloud. The ﬁrst tool, TradeOffBoard, is a dashboard

intended to help organisations in ﬁnding the best ar-

chitecture for deployment of CAC schemes. We high-

light that TradeOffBoard is already extensively de-

scribed in (Berlato et al., 2020) as a “Web Dashboard”

and it is not a novel contribution of this paper. In-

stead, we only illustrate its use in the context of CO-

ERCIVE. Our main contribution lies instead in the

implementation and thorough performance evaluation

https://github.com/stfbk/CryptoAC

370

Berlato, S., Carbone, R. and Ranise, S.

Cryptographic Enforcement of Access Control Policies in the Cloud: Implementation and Experimental Assessment.

DOI: 10.5220/0010608003700381

In Proceedings of the 18th International Conference on Security and Cryptography (SECRYPT 2021), pages 370-381

ISBN: 978-989-758-524-1

of the second tool, CryptoAC. CryptoAC is a Swiss

army knife tool for ﬂexible and portable enforcement

of role-based CAC policies in the cloud. CryptoAC

implements the CAC scheme proposed by (Garrison

et al., 2016). Moreover, CryptoAC supports dozens

of different architectures seamlessly and it is cloud-

independent, i.e., it can be deployed in any CSP with-

out needing extra conﬁguration.

The paper is structured as follows. In Section 2

we report the background. Then, in Section 3 we give

an overview of COERCIVE and motivate its need by

showing how it can be used, together with Trade-

OffBoard, in an eHealth scenario often considered

in cloud-related literature. Afterwards, we describe

design and implementation concerns of CryptoAC

in Section 4. To demonstrate the feasibility of our

approach, we provide a thorough performance evalu-

ation for CryptoAC to study its scalability and asymp-

totic behaviour with synthetic benchmarks in Sec-

tion 5. Finally, we report related work in Section 6

and conclude the paper in Section 7.

2 BACKGROUND

In this section, we introduce the concepts of AC (Sec-

tion 2.1) and CAC (Section 2.2).

2.1 Access Control

In (Samarati and de Capitani di Vimercati, 2000), AC

is deﬁned as “the process of mediating every request

to resources maintained by a system and determining

whether the request should be granted or denied”. Re-

sources usually consist of data such as ﬁles and docu-

ments. Role-Based Access Control (RBAC) is one of

the most widely adopted AC models for cloud com-

puting (Cai et al., 2019). In RBAC, users are assigned

to one or more roles. In an organization, a role reﬂects

an internal qualiﬁcation (e.g., employee). A permis-

sion p = hres, opi is deﬁned as an operation op (e.g.,

read) over a resource res (e.g., a ﬁle). Permissions are

assigned to one or more roles by administrators of the

policy. Users activate a role to access the permissions

needed to ﬁnalize their operations on resources (e.g.,

read a ﬁle). Formally, the state of an RBAC policy can

be described by the set of users U, roles R, permis-

sions P and the assignments users-roles UR ⊆ U × R

and roles-permissions PA ⊆ R × P. A user u can use a

permission p if ∃r : (hu, ri ∈ UR) ∧(hr, pi ∈ PA). Role

hierarchies can always be compiled away by adding

suitable pairs to UR.

Table 1: CAC schemes entities.

Entity Description

Proxy

Performs cryptographic computations, allowing users to access ﬁles

and the administrator to manage the AC policy

Mediates users’ requests to add and write ﬁles by ensuring compli-

ance with the AC policy

MS Stores metadata

DS Stores encrypted data

2.2 Cryptographic Access Control

Partially trusted environments (e.g., the cloud) pre-

serve the integrity and availability of data but not

their conﬁdentiality (Garrison et al., 2016). In this

case, cryptography is often used to enforce AC while

ensuring the conﬁdentiality of sensitive data. These

data are encrypted and the permission to read the

encrypted data is embodied by the secret decrypting

keys. While implying a further computational burden

(i.e., the cryptographic computations) and additional

metadata (e.g., public keys), CAC allows encrypted

data to be stored in partially trusted environments.

Usually, CAC schemes involve four entities (Berlato

et al., 2020), i.e., a proxy, a Reference Monitor (RM),

a Metadata Storage (MS) and a Data Storage (DS),

which we describe in Table 1

Below, we give an intuition of the functioning of

the CAC scheme proposed in (Garrison et al., 2016)

for enforcing role-based CAC policies. Each user u

and role r is provided with a pair of secret and pub-

lic keys (k

, k

) and (k

, k

), respectively. The con-

tent f of each ﬁle fn is encrypted with an individual

(i.e., different for each ﬁle) symmetric key k

sym

. To

assign u to r, r’s secret key k

is encrypted with k

resulting in {k

}

. To give permission over a ﬁle fn,

the symmetric key k

sym

related to the ﬁle is encrypted

with k

, resulting in {k

sym

}

. The use of both asym-

metric and symmetric cryptography is usually called

“Hybrid Encryption” (Garrison et al., 2016). An op-

eration op can be either read (R) or read-write (RW ).

The CAC policy is represented by decorated versions

of the relations UR and PA, i.e. {k

}

is attached

to the pair hu, ri in UR whereas {k

sym

}

is attached

to the pair hr, pi in PA; by abusing notation, we write

hu, r,{k

}

i and hr, p,{k

sym

}

i, respectively and,

together with public cryptographic keys, we refer to

these extended tuples as metadata. In (Garrison et al.,

2016), metadata contain additional information (e.g.,

digital signatures for authenticity and integrity) that

we omit here for the sake of simplicity.

Besides read and write operations, the CAC

scheme in (Garrison et al., 2016) speciﬁes also admin-

istrative operations for managing the AC policy such

as adding and deleting users, roles, ﬁles and assign-

Cryptographic Enforcement of Access Control Policies in the Cloud: Implementation and Experimental Assessment

371

Table 2: CAC scheme operations.

Operation Description

addU(u): add u in U

deleteU(u):

delete u from U ; ∀r ∈ R : ∃hu, r,{k

}

i ∈ UR, revokeU(u, r)

addR(r): add r in R

deleteR(r):

delete r from R; ∀fn :

∃hr, hfn, ∗i,{k

sym

}

i ∈ PA,

revokeP

(r, fn)

addF(fn, f ): add hfn, ∗i in P and f in DS

deleteF(fn):

delete hfn, ∗i from P and f from DS;

delete all h∗, hfn, ∗i, ∗i from PA

assignU(u, r): add hu, r,{k

}

i in UR

revokeU(u, r):

delete hu, r,{k

}

i from UR; update

r’s keys in all h∗, r, ∗i ∈ UR; update

fn’s keys in all h∗, hfn, ∗i, ∗i ∈ PA :

∃hr, hfn, ∗i,{k

sym

}

i ∈ PA

assignP(r, fn, op): add hr, hfn, opi,{k

sym

}

i in PA

revokeP

(r, fn):

change hr, hfn, RWi,{k

sym

}

i to

hr, hfn, Ri,{k

sym

}

revokeP

(r, fn):

delete all hr, hfn, ∗i,{k

sym

}

i from PA;

update fn’s keys in all h∗, hfn, ∗i, ∗i ∈ PA

readF(fn):

decrypt {k

}

with k

, then {k

sym

}

with k

and ﬁnally { f }

sym

with k

sym

writeF(fn, f

encrypt f

with k

sym

ing and revoking users and permissions to roles. We

brieﬂy describe all operations in Table 2. We use the

character “*” as a wildcard in tuples for UR and PA

assignments. For instance, {h∗, r, ∗i ∈ UR} represents

the set of UR assignments related with r (i.e., the set

of users assigned to r). We highlight that, whenever

RW permission over a ﬁle fn is revoked from a role

r (revokeP

(r, fn) operation), the related key k

sym

is discarded and a new key k

sym

is generated. This

mechanism prevents r from still being able to decrypt

the content f of fn. The same behaviour applies when-

ever a user u is revoked from a role r (revokeU(u, r)

operation), i.e., r’s keys are renewed to prevent u from

still having access to r’s permissions. As u may have

cached keys for future access, also the keys of all ﬁles

r has permission over are replaced. For better per-

formance, the content f of a ﬁle fn is not immedi-

ately re-encrypted (i.e., active re-encryption) but in-

stead it is re-encrypted with the new key k

sym

by the

next user to write to the ﬁle (i.e., lazy encryption).

For more details about the construction of the CAC

scheme, please refer to (Garrison et al., 2016).

3 COERCIVE OVERVIEW

In this section, we give an overview of the toolchain

COERCIVE (see Figure 1). We ﬁrst motivate its need

*deploy Optimal

Architecture*

CryptoAC

Organisation

TradeOffBoard

Users

*use*

Proxy

optimisation



Scenario

Requirements

Optimal

Architecture

Admin

Figure 1: COERCIVE overview.

by describing an eHealth scenario often considered in

the cloud-related literature (Section 3.1). Then, we

show how to apply TradeOffBoard in such a scenario

(Section 3.2). We highlight that CryptoAC is instead

extensively described in Section 4.

3.1 The eHealth Scenario

We start from the consideration that different scenar-

ios may have speciﬁc requirements to satisfy. At a

high-level, COERCIVE allows organisations to eval-

uate CAC scheme architectures against these require-

ments (TradeOffBoard box in Figure 1) and then de-

ploy the optimal architecture for the scenario under

consideration (CryptoAC box in Figure 1).

To understand why these are crucial activities, we

consider the following scenario adapted from the lit-

erature on outsourcing medical data to the cloud (Ho-

randner et al., 2016; Sato and Fugkeaw, 2015; Pre-

marathne et al., 2016). Suppose a person with a men-

tal disorder is hospitalized in a specialized clinic. The

clinic is storing in the cloud the patients’ data en-

crypted under a CAC scheme. However, the CAC

scheme expects the patient’s name to be part of the

metadata (e.g., in the AC policy or in the ﬁles name);

the CSP may then infer that a speciﬁc person is a cus-

tomer of the clinic and share this information for tar-

geted advertisement. This is an instance of a well-

known requirement (see, e.g., (Domingo-Ferrer et al.,

2019)) which states to hide not only medical data but

also metadata from CSPs. Moreover, this may not

be the only requirement to consider; others may in-

clude the use of hardened devices only for process-

ing medical data, the prioritization of redundancy to

avoid data loss, the maximization of CSP (monetary)

savings and the minimization of the vendor lock-in.

However, different architectures satisfy these re-

quirements at different levels. Even worse, these re-

quirements may conﬂict with each other, leading to a

stalemate in which we need to carefully evaluate the

beneﬁts and drawbacks of different architectures. For

instance, while enabling ubiquitous access, allowing

employees to use personal computers is against the re-

quirement of using hardened devices only. Then, the

setup of a data-centre on-premise may be unappeal-

SECRYPT 2021 - 18th International Conference on Security and Cryptography

372

Proxy

Proxy RM

Figure 2: Two architectures for CAC schemes in the cloud.

ing for small clinics, for they may lack the skills and

resources to efﬁciently manage it. Although moving

some services to the cloud may enhance redundancy

and scalability, it would threaten (sensitive) metadata

and suffer from high CSP-related monetary costs and

the vendor lock-in effect. In this context, COERCIVE

supports the investigation of alternative CAC archi-

tectures (by using TradeOffBoard) and then deploy

the selected one (by using CryptoAC).

3.2 TradeOffBoard Optimisation

To accomplish its tasks, a CAC entity (i.e., proxy,

RM, MS or DS) must be deployed in a location or

“domain” (e.g., software needs to run on a machine).

For CAC schemes targeting cloud-hosted data, there

exist three possible domains (Berlato et al., 2020),

i.e., client

(e.g., the user u’s computer), on-premise

(e.g., a data-centre within the organisation) and the

CSP. It naturally follows that there are multiple ways

to assign entities to domains, i.e., there are several ar-

chitectures for CAC schemes (e.g., see Figure 2 for

two examples). An architecture may have multiple

instances of the same entity under different domains.

Moreover, an architecture does not deﬁne which CSP

to use (e.g., AWS, Azure, GCP).

Figure 3: TradeOffBoard screenshot.

As an illustrative example, we input in TradeOff-

Board the requirements of the eHealth scenario de-

scribed in Section 3.1 (see Figure 3). TradeOffBoard

presents a ﬁrst block “Pre-Filters” in which an or-

ganisation can exclude the presence of an entity in

a domain. For the eHealth scenario, we set the Pre-

Filters so to avoid the deployment of the proxy in

the client

domain (to avoid personal devices) and the

MS in the CSP domain only (to avoid the disclosure

of sensitive metadata to the CSP). Then, the “Sce-

nario Requirements” block allows prioritizing a set

of relevant architectural requirements (e.g., reliabil-

ity, maintenance) identiﬁed in (Berlato et al., 2020).

This set is not ﬁxed, and requirements can be added

and removed according to the scenario under investi-

gation. Following the description of the eHealth sce-

nario in Section 3.1, we prioritize redundancy by as-

signing a higher weight with respect to other require-

ments. Then, we set a (soft) constraint on the ven-

dor lock-in requirement (i.e., to allow architectures

suffering from the vendor lock-in effect at the cost

of a penalty). Finally, we set a (hard) constraint on

CSP (monetary) savings (i.e., to exclude architectures

leading to signiﬁcant CSP related expenses).

Based on how each architecture satisﬁes these re-

quirements, TradeOffBoard solves the optimisation

problem and proposes a ranking of the architectures

in the “Best Architectures” block. For the eHealth

scenario, TradeOffBoard proposes three best archi-

tectures. These avoid the use of the client

domain

as expected by the Pre-Filters. Moreover, the MS is

either deployed in the on-premise domain only (ar-

chitecture #1) or in a hybrid fashion between the on-

premise and the CSP domains (architectures #2 and

#3) so to always protect sensitive metadata. To en-

hance redundancy, the DS is always deployed in the

CSP domain. Nonetheless, to limit the vendor lock-

in effect and CSP monetary expenses, entities deploy-

ment is balanced between the on-premise and the CSP

domains. As a ﬁnal remark, we highlight that Trade-

OffBoard solves the optimisation problem in few mil-

liseconds. For more details on TradeOffBoard and its

performance evaluation, we refer the interested reader

to (Berlato et al., 2020).

4 CryptoAC

As highlighted in Section 1, the (few) prototypes im-

plementing CAC schemes available in the literature

can usually interact with one CSP only and have a

ﬁxed (or unspeciﬁed) architecture; this makes them

unsuitable for real-world deployment, as they lack in

particular portability (across different CSPs) and (ar-

chitectural) ﬂexibility.

Cryptographic Enforcement of Access Control Policies in the Cloud: Implementation and Experimental Assessment

373

To ﬁll this gap, we propose CryptoAC, a fully

working and usable implementation of the CAC

scheme proposed by (Garrison et al., 2016). Con-

cretely, CryptoAC is composed of four software mod-

ules (see Table 3), one for each CAC scheme entity

presented in Section 2.2 (i.e., proxy, RM, MS and

DS). We highlight that we followed development best

practices (e.g., Test-Driven Development, Continuous

Integration pipelines) for producing quality software.

In this section, we ﬁrst explain the use of

container technology to achieve cloud-independency

(Section 4.1). Then, we describe the implementa-

tion of the proxy (Section 4.2), RM (Section 4.3), MS

(Section 4.4) and DS (Section 4.5) modules. Finally,

we discuss CryptoAC multiple architectures support

and deployment (Section 4.6). For the sake of brevity,

here we do not discuss security aspects not relevant

research-wise such as the use of TLS for establishing

secure channels or of cryptographic certiﬁcates for

mutual authentication between CryptoAC modules.

4.1 Cloud-independency

We choose to use the microservice architecture,

that consists of logically splitting an application into

loosely coupled services (usually called containers),

where each service is self-contained and implements

a single functionality with clear interfaces.

To enable the microservice paradigm in our con-

text, we ship our modules in Docker images.

, a

read-only templates containing instructions to cre-

ate containers, which run on the Docker platform in

an isolated environment. All major CSPs provide

support for running containers (e.g., AWS,

Azure

and GCP

). Using Docker, CryptoAC achieves cloud-

independency and can therefore be used in any (com-

bination) of these CSPs.

As it usually happens, CryptoAC Docker images

are built on other base images, with some additional

customization. The Docker image of the MS mod-

ule is built on top of the ofﬁcial MySQL database im-

age over which we provide an .sql ﬁle for creating

the database (e.g., tables, views, triggers) of metadata.

The remaining three entities (i.e., proxy, RM and DS)

cannot be implemented just as easily since they need

to support particular functionalities. To avoid code

duplication and enhance maintainability, we imple-

https://developer.ibm.com/articles/why-should-we-use-

microservices-and-containers

https://www.docker.com/

https://aws.amazon.com/ecs/?nc1=h

https://azure.microsoft.com/en-gb/product-

categories/containers/

https://cloud.google.com/sdk/gcloud/reference/container

Table 3: CryptoAC software modules.

Entity Base Docker Implementation HTTP RESTful APIs

Proxy Java Program 22 (10 proﬁles,12 AC)

RM Java Program 3 (add/write ﬁle, conﬁgure)

MS .sql ﬁle - (MySQL protocol)

DS Java Program 4 (CRUD Paradigm)

ment all three entities in a single Java program. Its

Docker image is built on top of the ofﬁcial OpenJDK

Docker image. At startup, each container is conﬁg-

ured with an operation mode that speciﬁes which en-

tity (i.e., either proxy, RM or DS) the instance should

support. Each container can support one entity at a

time. Besides, it is possible to ﬁne-tune several pa-

rameters (e.g., cryptographic algorithms, key size) di-

rectly from the command line.

4.2 Proxy

The proxy module interfaces users with data (e.g.,

through read and write requests, as explained in Sec-

tion 2.2) by performing cryptographic computations.

Besides users, the administrator uses the proxy mod-

ule to manage the AC policy. In particular, the admin-

istrator can create and delete users, roles, ﬁles and dis-

tribute assignments and permissions, i.e., the admin-

istrator can modify U, R, P UR and PA by sending an

(authenticated and signed) request to the MS module.

The proxy module has to be conﬁgured with relevant

information to interact with the other modules (e.g.,

URLs, cryptographic certiﬁcates, credentials).

Each operation performed by a user u (e.g., write

a ﬁle) or the administrator (e.g., assign a user to a

role) is digitally signed with k

(or, since we are con-

sidering RBAC, with the private signing key of the

role k

that was assumed by the user to perform the

operation). Digital signatures protect encrypted data

and metadata against accidental or malicious modiﬁ-

cations by providing integrity and authenticity. Users,

roles and ﬁles have an identiﬁer (i.e., username, role

name and ﬁle name) and a random token of 50 bytes

acting as a pseudonym. When a user digitally signs

an operation, he/she appends his/her (or the assumed

role’s) token instead of his/her (or the role’s) identi-

ﬁer. In this way, users can fetch public signing keys to

verify signatures without learning the identity of the

user (or role) that created the signature. Finally, users

and roles are assigned a status, either “incomplete”

(i.e., created but not fully conﬁgured), “operational”

(i.e., ready for use) or “deleted” (by the administra-

https://github.com/stfbk/CryptoAC

SECRYPT 2021 - 18th International Conference on Security and Cryptography

374

tor). Public cryptographic keys of deleted users and

roles are kept to verify digital signatures.

Web Application. The proxy module offers a web

User Interface (UI), developed with JQuery,

Boot-

strap

and the Apache Template Engine.

The proxy

module uses the Spark Java framework

to setup a

web server and expose two sets of RESTful APIs. The

ﬁrst set is related to the management of users’ pro-

ﬁles; a user’s proﬁle contains the user’s secret cryp-

tographic keys (generated within the proxy) along

with other conﬁgurations data (set through the UI)

like username, password and URLs of other modules.

The second set is related to the management of the

AC policy; these APIs have a 1-to-1 mapping with

administrative operations, i.e., add and delete users,

roles and ﬁles, read and write ﬁles and distribute and

revoke assignments and permissions. These opera-

tions are available via a UI for administrators, which

presents only add, read and write operations to nor-

mal users. All the inputs to the web UI are validated

against OWASP-approved regular expressions

avoid web-based attacks (e.g., injection, Cross-Site

Scripting).

4.3 Reference Monitor

When CryptoAC is conﬁgured to act as a RM, it reg-

isters three APIs. The ﬁrst one is reserved for the

administrator and allows to conﬁgure the RM mod-

ule (e.g., by providing URLs of other modules). The

other two APIs are for adding and writing ﬁles, re-

spectively. When a user wants to add a new ﬁle,

the RM module checks whether the user is granting

to the administrator all permissions over the ﬁle. To

counter malicious users who keep adding useless ﬁles

to exhaust resources (e.g., storage space), we can sim-

ply implement a mechanism to limit the number (or

size) of ﬁles each user can upload. When a user u

wants to write over a ﬁle, the RM queries the AC

policy in the MS to ensure that u has the permis-

sion to do it. While it would provide two layers of

security, we follow the scheme in (Garrison et al.,

2016) and do not make the RM module mediate read

requests too, as this control is cryptographically en-

forced (see Section 2.2). Again, to counter malicious

users and Denial-of-Service attacks, we can imple-

https://jquery.com/

https://getbootstrap.com/

https://velocity.apache.org/

http://sparkjava.com/

https://owasp.org/www-community/OWASP Validation

Regex Repository

ment a mechanism to limit the number of ﬁles a user

can upload or send a warning to the administrator.

4.4 Metadata Storage

When starting the MS module, we initialise the

MySQL database by creating tables “users” for U,

“roles” for R, “roleTuples” for UR and “permission-

Tuples” for PA. Furthermore, we create two addi-

tional tables to contain ﬁle-related metadata like sta-

tus ﬂags and version numbers, i.e., “ﬁles” and “ﬁle-

Tuples”.

To hide (potentially sensitive) identiﬁers

and avoid the disclosure of the AC policy to the users,

we limit users’ Select privileges to grant access to

tokens only and employ views and row-level permis-

sions. In practice, we deﬁne views over the “role-

Tuples” and “ﬁleTuples” tables which automatically

ﬁlter assignments not associated with the user query-

ing the database, whose username is available through

the USER() MySQL function.

In this way, each user

knows his portion of the AC policy only and we re-

spect the need-to-know principle (i.e., each user has

access only to the information strictly needed to ac-

complish his task).

Finally, to avoid SQL injection and (stored) Cross-

Site Scripting attacks, inputs to the database are san-

itized with the PreparedStatement Java class,

while outputs from the database are sanitized using

the OWASP Java Encoder.

4.5 Data Storage

The DS module registers four APIs following the

Create, Read, Update and Delete (CRUD) paradigm.

Normal users can invoke the Read API, while Cre-

ate, Update and Delete APIs can be invoked by the

administrator and the RM module only. The CAC

scheme in (Garrison et al., 2016) expects both new

and overwritten (encrypted) ﬁles to be uploaded from

the proxy to the RM. Then, the RM has to check the

legitimacy of users’ requests and, if everything is con-

ﬁrmed, send the ﬁles to the DS. However, we note that

this two-hop approach may waste bandwidth and cre-

ate a bottleneck in the RM module. As such, we mod-

ify this behaviour so that ﬁles are instead uploaded

from the proxy module to the DS module and stored

in a temporary upload directory. Then, the proxy asks

the RM module to check the users’ requests and, if

https://github.com/stfbk/CryptoAC

https://dev.mysql.com/doc/refman/8.0/en/information-

functions.html

https://docs.oracle.com/javase/tutorial/jdbc/basics/

prepared.html

https://owasp.org/owasp-java-encoder/

Cryptographic Enforcement of Access Control Policies in the Cloud: Implementation and Experimental Assessment

375

everything is conﬁrmed, the RM module asks the DS

module to move the ﬁles in the actual storage direc-

tory from which users can download them. Other-

wise, the ﬁles are simply discarded.

4.6 Multiple Architectures Support

CryptoAC initially inherits the ability to support mul-

tiple architectures from the CAC scheme we chose to

implement (Garrison et al., 2016). Indeed, the au-

thors proved that in their scheme the proxy entity can

be deployed both in the client

and on-premise do-

mains. Moreover, they assumed the RM, DS and MS

entities to stay in the CSP domain; it follows that de-

ploying these entities on-premise instead is possible,

as they would move from a partially trusted domain

(i.e., CSP) to a fully trusted one (i.e., on-premise).

We preserve support for multiple architectures

by making the proxy, RM and DS modules ex-

pose RESTful APIs (documented with Swagger Ope-

nAPI) returning JSON-formatted responses to guar-

antee maximum ﬂexibility. By deﬁning clear inter-

faces for accessing inner functionalities, each module

is self-contained and independent from the location of

other modules. Besides, this approach allows Cryp-

toAC to be easily integrated with other services (e.g.,

as a plugin for a text editor). Finally, we implement

the proxy module so that one instance can serve mul-

tiple users (i.e., the proxy module can be deployed

both in the client

and on-premise domains). By ef-

fectively decoupling the deployment from the imple-

mentation, CryptoAC results to be fully agnostic with

respect to the chosen architecture, i.e., the code of

CryptoAC requires no modiﬁcation when supporting

different architectures.

Deployment. An organisation can easily use avail-

able tools such as Cloudify,

Kubernetes

Docker-compose

to deploy CryptoAC, based on the

chosen architecture. As a proof-of-concept, we pro-

pose a simple docker-compose ﬁle for quick local de-

ployment and make it available along with the source

code of CryptoAC.

We note that the local deploy-

ment can automatically be ported to the cloud us-

ing new docker-compose features for integration with

AWS and Azure. Finally, as we employ the Data Ac-

cess Object (DAO) pattern for decoupling the logic of

the CAC scheme from the management (e.g., storage,

retrieval) of metadata and encrypted data, CryptoAC

modules can be easily replaced by other services. For

https://cloudify.co/

https://kubernetes.io/

https://docs.docker.com/

https://github.com/stfbk/CryptoAC

instance, the code of the RM module could be ported

in an AWS Lambda service, while AWS RDS could

be used as MS and AWS S3 as DS.

5 PERFORMANCE EVALUATION

In this section, we propose a thorough performance

evaluation for CryptoAC. First, we measure the ex-

ecution time of each operation described in Table 2

(Section 5.1). However, the performance of some op-

erations is not constant, but instead it is inﬂuenced by

the state of the AC policy. For instance, whenever the

administrator revokes a permission from a role r over

a ﬁle fn, the related key k

sym

is discarded and a new

key k

sym

is generated (see Section 2.2). However,

the new key k

sym

has to be distributed to (i.e., en-

crypted with the public key of) all other roles which

still have access to f n. Depending on the number of

these roles, this operation may take more or less time.

Therefore, we also explore more in detail the perfor-

mance of those operations whose execution time de-

pends on the state of the AC policy (Section 5.2).

5.1 Evaluation Per Operation

We report in Table 4 the performance evaluation of

CryptoAC for each operation described in Table 2.

We omit the operations for deleting users and roles as

their timings can be derived in a straightforward way

from revokeU(u, r) and revokeP

(r, fn), respectively.

We use the symbol |·| for representing the cardinality

of a set (i.e., the number of its elements). We run all

tests 1,000 times to reduce measurements errors on a

Ubuntu 18.04 Virtual Machine with 4 threads on an

Intel(R) Core(TM) i7-7700HQ and 8GB of RAM.

In the “Cryptographic Computations” column, we

list the number and type of cryptographic computa-

tions involved in each operation, as described in (Gar-

rison et al., 2016), namely generation, encryption, and

decryption for symmetric-key (Gen

, Enc

, Dec

)

and public-key (Gen

, Enc

, Dec

) cryptography to-

gether with generation and veriﬁcation of digital sig-

natures (Gen

Sig

, Ver

Sig

). Asymmetric keys are RSA

2048, while symmetric keys are AES 256. Enc

and

Dec

encrypt and decrypt a pair of asymmetric keys

(4096 bits) while the execution times of Enc

and

Dec

are calculated per MB of data. Signatures are

256 bytes long and are generated from 16,743 bytes

of data (i.e., the biggest block of metadata that is pro-

duced (Garrison et al., 2016)). We measure the execu-

tion time of each computation individually using the

SECRYPT 2021 - 18th International Conference on Security and Cryptography

376

Table 4: Cryptographic computations per operation and execution time (in milliseconds).

Operation Cryptographic Computations Cryptographic Time Implementation Time

addU(u): 2 · Gen

225.346 276.612

addR(r): 2 · (Gen

+ Enc

) + Gen

Sig

227.836 255.192

addF(fn, f ):

2 · (Gen

Sig

+ Ver

Sig

) + Gen

+ Enc

4.300 + Enc

59.804 + Enc

deleteF(fn): No cryptographic computation involved 0 45.817

assignU(u, r):

2 · (Enc

+ Dec

) + Gen

Sig

+ Ver

Sig

26.731 68.770

revokeU(u, r):

Dec

+ (2 · Enc

+ Gen

Sig

+ Ver

Sig

)·|{h∗,ri∈UR}|+

(Gen

)·|{hr,∗i∈PA}| + (Enc

+ Gen

Sig

+ Ver

Sig

)·

|{h∗,hfn,∗ii∈PA:∃hr,hfn,∗ii∈PA}| + 2 · Gen

(2.759)·|{h∗,ri∈UR}|+

(0.033)·|{hr,∗i∈PA}|+

(2.342)·|{h∗,hfn,∗ii∈PA:∃

hr,hfn,∗ii∈PA}|+ 237.33

(19.423)·|{h∗,ri∈UR}|+

(9.872)·|{hr,∗i∈PA}|+

(6.791)·|{h∗,hfn,∗ii∈PA:∃

hr,hfn,∗ii∈PA}|+ 247.735

assignP(r, fn, ∗):

if ∃hr,hfn,∗ii∈PA, Gen

Sig

+ 2 · Ver

Sig

;

else, Gen

Sig

+ 2 · Ver

Sig

+ Enc

+ Dec

if ∃hr,hfn,∗ii∈PA, 2.194;

else, 14.597

if ∃hr,hfn,∗ii∈PA, 7.385;

else, 49.167

revokeP

(r, fn):

2 · (Ver

Sig

+ Gen

Sig

) 3.850 45.674

revokeP

(r, fn):

Gen

+(Ver

Sig

+Enc

+Gen

Sig

)·|{hr

,hfn,∗ii∈PA:r6=r

(2.342)·|{hr

,hfn,∗ii∈PA:

r6=r

}|+ 0.033

(37.360)·|{hr

,hfn,∗ii∈PA:

r6=r

}|+ 0.034

readF(fn): 3 · Ver

Sig

+ 2 · Dec

+ Dec

24.779 + Dec

45.559 + Dec

writeF(fn, f

5 · Ver

Sig

+ 2 · (Dec

+ Gen

Sig

) + Enc

28.629 + Enc

62.145 + Enc

Table 5: Cryptographic computations execution time.

Gen

0.033ms Gen

112.673ms

Enc

11.860ms/MB Dec

16.820ms/MB

Enc

0.417ms Dec

11.986ms

Gen

Sig

1.656ms Ver

Sig

0.269ms

default SUN Java cryptographic provider

and report

the results in Table 5. In the “Cryptographic Time”

column, we calculate the execution time of each op-

eration by summing the execution time of all crypto-

graphic computations involved (taken from Table 5).

For instance, the addU(u) operation involves the gen-

eration of two pairs of asymmetric keys (for encryp-

tion and digital signatures). As the execution time for

Gen

is 112.673ms, the execution time of addU(u)

is 2 · 112.673 ms = 225.346 ms. The performance

of revokeU(u, r) and revokeP

(r, fn) depends on the

status of the RBAC policy; they are discussed in Sec-

tion 5.2. In the “Implementation Time” column, we

measure the execution time of each operation when

running CryptoAC. This includes the time spent for

the cryptographic computations and the overhead due

to retrieving metadata from the MS database, connec-

tions among the modules, parameters validation, and

so on. To exclude network latency, we deployed all

docker containers on the same device used for testing.

From Table 4, we can see that the maximum

overhead brought by CryptoAC implementation is

58.504 ms addF(fn, f )) while the minimum is 20.78

ms (readF(fn)). While the overhead in percentage

points can be high (as the cryptographic time of some

https://docs.oracle.com/en/java/javase/11/security/oracle-

providers.html

operations is really low), the absolute values are rea-

sonably bounded to few dozens of milliseconds.

5.2 Policy-dependent Operations

We now discuss the performance of the

revokeP

(r, fn) and revokeU(u, r) operations.

The former is inﬂuenced by a single parameter, i.e.,

the number of roles having permission over fn (except

r), while the latter is inﬂuenced by three parameters,

i.e., the number of users assigned to r, the number of

ﬁles r has permission over and the number of roles

sharing a permission with r. We stress that these

parameters are related to the users, roles and ﬁles

concerned by the revokeP

(r, fn) and revokeU(u, r)

operations, and not to the total number of users, roles

and ﬁles in the AC policy (which may be more).

0 20 40 60 80 100

0 1000 2000 3000 4000

Number of Other Roles

Execution Time (ms)

2.34

37.36

3.84

Implementation Time

Cryptographic Time

Actual Execution Time

Linear Regression on Actual Execution Time

Figure 4: revokeP varying |{hr

, hfn, ∗ii ∈ PA : r 6= r

}|.

RevokeP. To determine whether the cryptographic

Cryptographic Enforcement of Access Control Policies in the Cloud: Implementation and Experimental Assessment

377

0 20 40 60 80 100

0 500 1000 1500 2000

Number of Users

Execution Time (ms)

2.76

19.42

4.46

Implementation Time

Cryptographic Time

Actual Execution Time

Linear Regression on Actual Execution Time

Figure 5: revokeU when

varying |{h∗, ri ∈ UR}|.

0 20 40 60 80 100

0 500 1000 1500 2000

Number of Files

Execution Time (ms)

0.03

9.87

2.43

Implementation Time

Cryptographic Time

Actual Execution Time

Linear Regression on Actual Execution Time

Figure 6: revokeU when

varying |{hr, ∗i ∈ PA}|.

0 20 40 60 80 100

0 500 1000 1500 2000

Number of Other Roles

Execution Time (ms)

2.34

6.79

2.37

Implementation Time

Cryptographic Time

Actual Execution Time

Linear Regression on Actual Execution Time

Figure 7: revokeU when varying

|{h∗, hfn, ∗ii ∈ PA : ∃hr, hfn, ∗ii ∈

PA}|.

0 20 40 60 80 100

0 1000 2000 3000 4000

Number of Users

Execution Time (ms)

4.46

3.28

5.87

4.69

Linear Regression With 1 Files

Linear Regression With 100 Files

Linear Regression With 200 Files

Linear Regression With 300 Files

Figure 8: revokeU when

varying |{h∗, ri ∈ UR}|

and |{hr, ∗i ∈ PA}|.

0 20 40 60 80 100

0 1000 2000 3000 4000

Number of Files

Execution Time (ms)

2.43

10.28

7.56

8.87

Linear Regression With 1 Roles

Linear Regression With 100 Roles

Linear Regression With 200 Roles

Linear Regression With 300 Roles

Figure 9: revokeU when

varying |{hr, ∗i ∈ PA}| and

|{h∗, hfn, ∗ii ∈ PA : ∃hr, hfn, ∗ii ∈

PA}|.

0 20 40 60 80 100

0 1000 2000 3000 4000

Number of Other Roles

Execution Time (ms)

2.37

1.09

0.25

2.81

Linear Regression With 1 Users

Linear Regression With 100 Users

Linear Regression With 200 Users

Linear Regression With 300 Users

Figure 10: revokeU when varying

|{h∗, hfn, ∗ii ∈ PA : ∃hr, hfn, ∗ii ∈ PA}|

and |{h∗, ri ∈ UR}|.

and implementation execution times presented in Ta-

ble 4 are accurate, we measure the actual execution

time of the revokeP

(r, fn) operation when varying

its inﬂuencing parameter from 1 to 100 (i.e., we run

the operation 100 times, each time increasing the

parameter by 1). We report the 100 measurements

in Figure 4 (dotted line) and model the actual ex-

ecution time through linear regression (solid line).

We derive the cryptographic (dashed line) and imple-

mentation (long-dashed line) execution times for each

point on the X axis by simply multiplying the base

values in the “Cryptographic Time” and “Implemen-

tation Time” columns of Table 4, respectively. Near

each line, we report the relative angular coefﬁcient.

RevokeU. We repeat the same process for the

revokeU(u, r) operation, with the only difference that

the execution time depends on three parameters. As

such, we measure the actual execution time when

varying these three parameters from 1 to 100 one by

one. In other words, we ﬁx two parameters to the

value of 1 while ranging on the remaining from 1 to

100. We report the results in Figure 5, 6 and 7.

To check the interdependency of these three pa-

rameters, we execute a further experiment. We repeat

the analysis while ranging two parameters at the same

time and report the results in Figure 8, 9 and 10.

Discussion. Excluding outliers in measurements

(due to, e.g., cache misses, operative system tasks),

in Figure 4, 5, 6 and 7 we observe that the crypto-

graphic execution time is a lower bound of the actual

time, while the implementation execution time is an

upper bound. We can justify this behaviour by consid-

ering that some costs (e.g., opening a MySQL connec-

tion toward the MS database) are incurred only once,

independently from the number of users, ﬁles or roles

involved. Consequently, these costs do not increase

proportionally to the number of elements involved,

while cryptographic costs instead do. In general, the

execution time of revokeP

(r, fn) and revokeU(u, r)

when varying a single parameter remains within rea-

sonable boundaries (i.e., less than half a second)

for any practical RBAC policy. This is true also

SECRYPT 2021 - 18th International Conference on Security and Cryptography

378

when varying the pairs of parameters (|{h∗, ri ∈ UR}|,

|{hr, ∗i ∈ PA}|) and (|{h∗, hfn, ∗ii ∈ PA : ∃hr, hfn, ∗ii ∈

PA}|, |{h∗, ri ∈ UR}|), the overhead being around 3

seconds (Figure 8) and at most 2 seconds (Figure 10).

In all cases, the slope of the lines obtained by linear

regression are gentle and suggest good scalability.

The behavior of revokeU(u, r) when varying the

pair (|{hr, ∗i ∈ PA}|, |{h∗, hfn, ∗ii ∈ PA : ∃hr, hfn, ∗ii ∈

PA}|) of parameters is less scalable because of the in-

terplay between them. Indeed, the third parameter

(i.e., the number of roles sharing a permission with

r) includes also the permissions of r itself (i.e., the

second parameter). Therefore, increases in the sec-

ond parameter imply increasing the third one as well.

The slope of the lines obtained by linear regression is

steeper than before; however, the overhead is at most

2 seconds for the maximum values of the parameters.

Finally, we observe that revokeP

(r, fn) and

revokeU(u, r) are administrative operations. As such,

they can be scheduled during low-load states (e.g.,

overnight) without affecting users’ operations. All ex-

perimental results are available online.

6 RELATED WORK

To the best of our knowledge, there is no toolchain

combining automated trade-off analysis for select-

ing the most suitable architecture with the deploy-

ment of CAC schemes as in COERCIVE. While refer-

ring to (Berlato et al., 2020) for the works related to

TradeOffBoard, we observe that several researchers

proposed high-level designs of CAC schemes, e.g.,

(Rezaeibagha and Mu, 2016) and (Bacis et al., 2016).

Given our focus on the implementation of crypto-

graphic enforcement of AC policies, below we focus

on works that are closely related to CryptoAC by con-

sidering tools from both the academia (Section 6.1)

and commercial contexts (Section 6.2).

6.1 Cryptographic Access Control

Schemes Implementations

In (Berlato et al., 2020), we proposed an architec-

tural model for CAC schemes to assist administra-

tors to evaluate different architectures. Our contribu-

tions stem from (Berlato et al., 2020), on top of which

we propose the toolchain COERCIVE and CryptoAC.

We avoid the use of Cloudify,

favor a (more ag-

ile) microservice approach based on containers (i.e.,

https://st.fbk.eu/complementary/SECRYPT2021 2

https://cloudify.co/

Docker) and provide the implementation of all enti-

ties (i.e., proxy, RM, MS and DS).

In (Sato and Fugkeaw, 2015), the authors im-

plemented a scheme with multiple data owners in

CLOUD-CAT to investigate scalability and performance

in read and write operations. However, they as-

sumed a ﬁxed architecture and did not discuss the in-

teraction with the CSP. In (Zhou et al., 2013), the au-

thors proposed a scheme with a ﬁxed architecture in

which a public cloud stores encrypted data (i.e., DS)

while a private cloud stores metadata (i.e., MS). How-

ever, we note that it may be unappealing for small

organisations to maintain both a public and a private

cloud. The authors implemented their scheme just for

analysing the performance of read and write op-

erations. In (Zarandioon et al., 2012), the authors

proposed a CAC scheme emphasizing users’ privacy

by enabling anonymous access to data. They imple-

mented a prototype (with a ﬁxed architecture) inter-

acting with AWS. Noticeably, they provided an inter-

face so that further CSPs can be supported. In (Tang

et al., 2012), Tang et al. proposed a scheme with a

quorum of key managers deployed as a centralized en-

tity. Users interact with a proxy running either in the

client

domain or on-premise; this is the ﬁrst scheme

allowing to slightly modify the architecture. More-

over, multiple CSPs can theoretically be supported.

In (Ghita et al., 2017), the authors implemented a

role-based CAC scheme. However, the architecture

is ﬁxed and many pragmatic aspects, like run-time

modiﬁcations to the AC policy, were overlooked. As

such, the scheme cannot be used in dynamic sce-

narios where permissions are assigned and revoked.

In (Qi and Zheng, 2019), the authors proposed a CAC

scheme similar to (Garrison et al., 2016) while using

onion encryption for revocation but obtaining worse

performance with respect to (Garrison et al., 2016)

(i.e., 7.2%). Each time a permission is revoked, the

CSP adds an encryption layer on each affected ﬁle.

For reading a ﬁle, an authorized user has to decrypt

all layers. The authors implemented their scheme in

a proof-of-concept prototype, Crypto-DAC. We note

that this approach implicitly assumes that no collu-

sion can happen between revoked users and the CSP.

In (Jang-Jaccard, 2018), the authors implemented a

CAC scheme based on ABE with AWS. Unfortu-

nately, the authors themselves admitted using a not

portable programming library. More importantly, the

scheme does not support the dynamicity of the pol-

icy. In (Djoko et al., 2019), the authors proposed a

CAC scheme leveraging Trusted Execution Environ-

ments (TEEs). The authors developed NEXUS to en-

force AC policies over shared volumes (i.e., at direc-

tory level) by encrypting each ﬁle in a volume with a

Cryptographic Enforcement of Access Control Policies in the Cloud: Implementation and Experimental Assessment

379

symmetric key. Each key is encrypted with the vol-

ume rootkey. Volume sharing happens by sending the

rootkey to other users through SGX Remote Attesta-

tion. Unfortunately, this scheme requires that each

user is equipped with a TEE.

Summarising, the focus of these works is mainly

proposing new CAC schemes with novel features. As

such, little space is left for additional analysis on al-

ternative architectures responsive to different scenar-

ios. As far as we know, CryptoAC is the only CAC

scheme implementation designed for real deployment

and not for performance evaluation only.

6.2 Commercial Tools

There are many free and commercial tools to protect

sensitive data stored in the cloud. However, the ma-

jority of these tools (e.g., Mega,

AxCrypt,

Krup-

tos 2,

Cubbit

) target individuals or have 1-to-1

sharing of data. Below, we focus on those tools which

target organisations and support protection against the

honest but curious CSP while enabling controlled in-

formation sharing among employees.

Qumulo

offers a software-deﬁned ﬁle system

running both on-premise and on CSPs like AWS and

GCP. From version 3.1.5, Qumulo features encryp-

tion at rest to preserve the conﬁdentiality of sensitive

data in on-premise clusters. Unfortunately, Qumulo

still relies on cloud-side encryption for cloud clusters,

not preventing CSPs from accessing sensitive data.

Zadara

is a storage solution compatible with AWS,

GCP and Azure. Although Zadara offers encryption

at rest, this feature is on a coarse-grained volume-by-

volume basis and is disabled by default. A volume is

encrypted with a symmetric key which is in turn en-

crypted with a master key derived from a user’s pass-

word. Boxcryptor

provides end-to-end encryption

and data sharing at both user and group level. Each

user has a pair of public-private keys, encrypted with

a symmetric key derived from the user’s password and

stored client-side. The modiﬁcation of the AC policy

following the revocation of permissions is not spec-

iﬁed in the technical report. LucidLink

simulates

a Network Attached Storage on users’ devices, while

data are stored in one of the supported CSPs. Each ﬁle

is encrypted using AES-256, and the encryption key

https://mega.nz/

https://www.axcrypt.net/

https://www.kruptos2.co.uk/

https://www.cubbit.io/technology

https://qumulo.com/

https://www.zadara.com/

https://www.boxcryptor.com

https://www.lucidlink.com/

Table 6: Comparison with commercial tools.

Mega

AxCrypt

Kruptos2

Cubbit

Qumulo

Zadara

Boxcryptor

LucidLink

CryptoAC

Open Source l l l

Multi-Platform l l l l l l l l l

Mobile Support l l l l l l

Fine-grained AC l l

All Features Free l

Policy Dynamicity l l l l ? ? l

Multi-Cloud Support l l l l l l

Flexible Architecture l l l

Optimised Architecture l

Conﬁdentiality w.r.t. CSP l l l l l l l l

Two-Factor Authentication l l l

Chat and Video Calls Support l l

Free for non-commercial use only;

Through browser only;

of the parent folder wraps each ﬁle key. The admin-

istrator gives a user access to a folder (or ﬁle) by en-

crypting the key of the folder (or ﬁle) with the user’s

public key. Metadata are synchronized through a cen-

tral service provided by LucidLink. Again, the mod-

iﬁcation of the AC policy following the revocation of

permissions is not speciﬁed in the technical reports.

Summarising, there are several tools for preserv-

ing the conﬁdentiality of data stored in partially

trusted CSP while also enforcing AC policies. How-

ever, these tools suffer several drawbacks with respect

to COERCIVE, including the lack of support for or-

ganisations (i.e., Mega, AxCrypt, Kruptos 2, Cubbit),

incomplete protection of data (i.e., Qumulo), coarse-

grained AC (i.e., Zadara), or constraints on the archi-

tecture to adopt (i.e., Boxcryptor and LucidLink re-

quire a central service to function). While not hav-

ing the same level of maturity of these tools—for

instance, some tools support two-factor authentica-

tion and chats and video-calls—CryptoAC instead ad-

dresses exactly these issues, as shown in Table 6.

7 CONCLUSION

In this paper, we have proposed COERCIVE, a

toolchain for optimal enforcement of CAC policies

in the cloud. COERCIVE is composed of two tools:

TradeOffBoard and CryptoAC. The former is al-

ready described in (Berlato et al., 2020) and it al-

lows for identifying the most suitable architecture

among dozens of possible alternatives for a given

use case scenario by automatically solving an opti-

mization problem. The latter is instead an original

contribution and allows for the portable and efﬁcient

deployment of a cryptographic enforcement of role-

based AC policies in several CSPs by using (Docker)

SECRYPT 2021 - 18th International Conference on Security and Cryptography

380

containers technology. Furthermore, we conducted

a thorough performance evaluation of CryptoAC to

demonstrate its scalability and efﬁciency. COER-

CIVE is available online as open-source software.

Future Directions. We are implementing further

functionalities of CryptoAC, like multi-administrator

support and tree-based ﬁle sharing. Moreover, we

are working on the secure management of crypto-

graphic material (e.g., users’ private keys) to seam-

lessly support solutions like Trusted Execution Envi-

ronments. To extend the applicability of COERCIVE,

we are planning to integrate CryptoAC with Hyper-

ledger Fabric to replace the cloud with a decentralized

solution. Finally, in this paper we analyzed the per-

formance of CryptoAC with respect to scalability and

asymptotic behaviours, which may be unlikely in real-

world scenarios. To further study the performance of

CryptoAC, we are developing a dedicated simulator to

evaluate CryptoAC on arbitrary AC policies through

real-world workﬂows (i.e., sequences of operations).

ACKNOWLEDGMENTS

The authors were supported in part by the Integrated

Framework for Predictive and Collaborative Secu-

rity of Financial Infrastructures (FINSEC) project and

the 5G-CARMEN project that received funding from

the European Union’s Horizon 2020 Research and

Innovation Programme under grant agreements no.

786727 and no. 825012, respectively.

REFERENCES

Bacis, E., De Capitani di Vimercati, S., Foresti, S.,

Paraboschi, S., Rosa, M., and Samarati, P. (2016).

Mix&slice: Efﬁcient access revocation in the cloud. In

Proceedings of the 2016 ACM SIGSAC Conference on

Computer and Communications Security, pages 217–

228. ACM.

Berlato, S., Carbone, R., Lee, A. J., and Ranise, S. (2020).

Exploring architectures for cryptographic access con-

trol enforcement in the cloud for fun and optimiza-

tion. In 15th ACM ASIA Conference on Computer and

Communications Security (ASIACCS 2020). ACM.

Cai, F., Zhu, N., He, J., Mu, P., Li, W., and Yu, Y. (2019).

Survey of access control models and technologies for

cloud computing. Cluster Computing, 22:6111–6122.

Djoko, J. B., Lange, J., and Lee, A. J. (2019). NeXUS:

Practical and secure access control on untrusted stor-

age platforms using client-side SGX. In 2019 49th

Annual IEEE/IFIP International Conference on De-

https://github.com/stfbk/CryptoAC

pendable Systems and Networks (DSN), pages 401–

413. IEEE.

Domingo-Ferrer, J., Farr

as, O., Ribes-Gonz

alez, J., and

anchez, D. (2019). Privacy-preserving cloud com-

puting on sensitive data: A survey of methods, prod-

ucts and challenges. Computer Communications, 140-

141:38–60.

Garrison, W. C., Shull, A., Myers, S., and Lee, A. J. (2016).

On the practicality of cryptographically enforcing dy-

namic access control policies in the cloud. In 2016

IEEE Symposium on Security and Privacy (SP), pages

819–838. IEEE.

Ghita, V., Costea, S., and Tapus, N. (2017). Implementation

of cryptographically enforced rbac. The Scientiﬁc Bul-

letin - University Politehnica of Bucharest, 79(2):9–3–

102.

Horandner, F., Krenn, S., Migliavacca, A., Thiemer, F., and

Zwattendorfer, B. (2016). CREDENTIAL: A Frame-

work for Privacy-Preserving Cloud-Based Data Shar-

ing. In 2016 11th International Conference on Avail-

ability, Reliability and Security (ARES), pages 742–

749, Salzburg, Austria. IEEE.

Jang-Jaccard, J. (2018). A Practical Client Application

Based on Attribute Based Access Control for Un-

trusted Cloud Storage. In Computer Science & In-

formation Technology, pages 01–15. Academy & In-

dustry Research Collaboration Center (AIRCC).

Premarathne, U., Abuadbba, A., Alabdulatif, A., Khalil, I.,

Tari, Z., Zomaya, A., and Buyya, R. (2016). Hybrid

Cryptographic Access Control for Cloud-Based EHR

Systems. IEEE Cloud Computing, 3(4):58–64.

Qi, S. and Zheng, Y. (2019). Crypt-DAC: Cryptographically

Enforced Dynamic Access Control in the Cloud. IEEE

Transactions on Dependable and Secure Computing,

pages 1–1.

Rezaeibagha, F. and Mu, Y. (2016). Distributed clinical data

sharing via dynamic access-control policy transforma-

tion. International Journal of Medical Informatics,

89:25–31.

Samarati, P. and de Capitani di Vimercati, S. (2000). Access

control: Policies, models, and mechanisms. In Fo-

cardi, R. and Gorrieri, R., editors, Foundations of Se-

curity Analysis and Design, volume 2171, pages 137–

196. Springer Berlin Heidelberg.

Sato, H. and Fugkeaw, S. (2015). Design and Implementa-

tion of Collaborative Ciphertext-Policy Attribute-Role

based Encryption for Data Access Control in Cloud.

Journal of Information Security Research, 6(3):71–

84.

Tang, Y., Lee, P. P., Lui, J. C., and Perlman, R. (2012). Fade:

Secure overlay cloud storage with ﬁle assured dele-

tion. IEEE Transactions on Dependable and Secure

Computing, 9(6):903–916.

Zarandioon, S., Yao, D., and Ganapathy, V. (2012). K2c:

Cryptographic Cloud Storage with Lazy Revocation

and Anonymous Access. In Rajarajan, M., Piper, F.,

Wang, H., and Kesidis, G., editors, Security and Pri-

vacy in Communication Networks, volume 96, pages

59–76. Springer Berlin Heidelberg, Berlin, Heidel-

berg.

Zhou, L., Varadharajan, V., and Hitchens, M. (2013).

Achieving Secure Role-Based Access Control on En-

crypted Data in Cloud Storage. IEEE Transactions

on Information Forensics and Security, 8(12):1947–

1960.

Cryptographic Enforcement of Access Control Policies in the Cloud: Implementation and Experimental Assessment

381