Secure Cloud Storage with Client-side Encryption using a Trusted

Execution Environment

Marciano da Rocha

1 a

, Dalton C

ezane Gomes Valadares

2,4 b

, Angelo Perkusich

3 c

Kyller Costa Gorgonio

4 d

, Rodrigo Tomaz Pagno

1 e

and Newton Carlos Will

1 f

Department of Computer Science, Federal University of Technology, Paran

a, Dois Vizinhos, Brazil

Department of Mechanical Engineering, Federal Institute of Pernambuco, Caruaru, Brazil

Department of Electrical Engineering, Federal University of Campina Grande, Campina Grande, Brazil

Department of Computer Science, Federal University of Campina Grande, Campina Grande, Brazil

Keywords:

Intel SGX, Data Sealing, File Encryption, Conﬁdentiality, Integrity, Secure Storage, Cloud Storage.

Abstract:

With the evolution of computer systems, the amount of sensitive data to be stored as well as the number

of threats on these data grow up, making the data conﬁdentiality increasingly important to computer users.

Currently, with devices always connected to the Internet, the use of cloud data storage services has become

practical and common, allowing quick access to such data wherever the user is. Such practicality brings with

it a concern, precisely the conﬁdentiality of the data which is delivered to third parties for storage. In the home

environment, disk encryption tools have gained special attention from users, being used on personal computers

and also having native options in some smartphone operating systems. The present work uses the data sealing,

feature provided by the Intel Software Guard Extensions (Intel SGX) technology, for ﬁle encryption. A virtual

ﬁle system is created in which applications can store their data, keeping the security guarantees provided by

the Intel SGX technology, before send the data to a storage provider. This way, even if the storage provider is

compromised, the data are safe. To validate the proposal, the Cryptomator software, which is a free client-side

encryption tool for cloud ﬁles, was integrated with an Intel SGX application (enclave) for data sealing. The

results demonstrate that the solution is feasible, in terms of performance and security, and can be expanded

and reﬁned for practical use and integration with cloud synchronization services.

1 INTRODUCTION

Cyber attacks and different cybercrimes are an in-

creasing threat to today’s digital society (Huang et al.,

2018; Khraisat et al., 2019; Singh et al., 2019). In

this context data governance and security is of utmost

importance (Onwujekwe et al., 2019). Reports from

specialized companies and government security enti-

ties indicate a growing number of threats to digital

data, whether from corporations or users. Companies

faced an average of 25 new threats per day in 2006,

up from 500,000 in 2016 (Weafer, 2016) and 61% of

https://orcid.org/0000-0002-8213-6803

https://orcid.org/0000-0003-1709-0404

https://orcid.org/0000-0002-7377-1258

https://orcid.org/0000-0001-9796-1382

https://orcid.org/0000-0001-9267-4982

https://orcid.org/0000-0003-2976-4533

CEOs are concerned with the state of the cyber secu-

rity of their company (PwC, 2016).

Nowadays, users are increasingly using cloud

storage services to keep their ﬁles and can access

them from any device connected to the Internet. Such

storage services hold a large set of data from various

users, including sensitive and conﬁdential informa-

tion, due to their reliance on such providers. However,

these storage services do not always guarantee or re-

spect the privacy of their users (Branscombe, 2015;

Cox, 2016; Clover, 2017).

One way to ensure an additional level of security

for users’ sensitive ﬁles is to encrypt such data be-

fore sending them to the cloud storage server. One

option that performs such an operation is using a disk

encryption system, which runs in the operating sys-

tem background and encrypts all information that is

stored.

This type of system has some vulnerabilities,

da Rocha, M., Valadares, D., Perkusich, A., Gorgonio, K., Pagno, R. and Will, N.

Secure Cloud Storage with Client-side Encryption using a Trusted Execution Environment.

DOI: 10.5220/0009130600310043

In Proceedings of the 10th International Conference on Cloud Computing and Services Science (CLOSER 2020), pages 31-43

ISBN: 978-989-758-424-4

which can highlight the risk of attacks and improper

access to data. One of these vulnerabilities is the

user’s password choice, which is often weak and can

be discovered using dictionary attacks, default pass-

words, rainbow tables or even brute force. Another

factor is that most of the existing disk encryption sys-

tems keep the encryption key in main memory while

it is running, allowing other malicious applications to

attack and discover the key.

Nowadays the use of reliable trusted hardware

technologies, such as Intel Software Guard Exten-

sions (Intel SGX) (INTEL, 2014) and ARM Trust-

Zone (Pinto and Santos, 2019), has grown. An In-

tel SGX application creates an isolated protected re-

gion of memory, which is called enclave, where data

are securely processed. Among the various features

provided by the SGX technology, there is the seal-

ing of an enclave data in secondary memory. This

process uses a unique key as a basis for the encryp-

tion, which is generated by combining a developer

key and a processor key, and is not stored in mem-

ory: it is generated again to each request, guarantee-

ing that the data will be decrypted only by the enclave

that sealed them, in the platform in which they were

sealed (Anati et al., 2013). Another feature provided

by Intel SGX technology is the encryption of data in a

region of primary memory with a random key that is

generated with each power cycle. This key is known

only by the processor and never goes beyond its limits

(INTEL, 2016).

According to the previous discussion, we estab-

lished the following two research questions to guide

our research:

1. How to improve the security of traditional disk en-

cryption tools?

2. How to decrease the user’s need to trust the cloud

service provider?

In this paper, we propose the use of Intel SGX

features to perform data sealing and processing in

a more secure way, since these operations are per-

formed only inside an enclave, which is supposed to

be protected even against adversaries with high priv-

ileges inside the operating system. We implemented,

as a proof of concept, an application using the Cryp-

tomator, an open source client-side encryption tool

used for cloud ﬁles protection. The Cryptomator was

modiﬁed, integrated with an Intel SGX application,

in order to use its data sealing feature, which is per-

formed only inside an enclave. With this, the data

encryption/decryption processes are performed in a

more secure way, extending this security also for the

keys, since they are also handled inside the enclave.

The main contributions of this work are listed be-

low:

• The proposal to improve the security of disk/ﬁle

encryption process using Intel SGX;

• The implementation of such proposal consider-

ing an Intel SGX application integrated with the

Cryptomator tool;

• The performance evaluation of our proposal im-

plemented, considering six different hardware

combinations.

The remainder of this paper is organized as fol-

lows: Section 2 provides background information

about the cloud storage and disk encryption tech-

niques, as well the Intel Software Guard Extensions

technology; Section 3 presents previous research

closely related to our proposal, in the ﬁeld of cloud

storage security and the use of Intel SGX in ﬁle en-

cryption; Section 4 describes the solution proposed by

this paper; in order to validate the proposed approach,

three prototypes are presented in Section 5 as a proof

of concept; Section 6 presents the performance evalu-

ation of the prototype on six different hardware com-

binations; the threat model as well the security eval-

uation of the Intel SGX technology and the proposal

solution are presented in Section 7; the limitations of

our solution are described in Section 8 and, ﬁnally,

Section 9 concludes the paper and presents the future

works.

2 BACKGROUND

This Section presents a brief description of important

concepts used in this work, such as cloud storage, disk

encryption and the Intel Software Guard Extensions.

2.1 Cloud Storage

Nowadays, more users are using cloud storage ser-

vices, either explicitly to keep their personal ﬁles, or

implicit through applications that make use of such

background services to maintain backups or history

of user data. The beneﬁts inherent in cloud data stor-

age are virtually unlimited storage, version history for

each ﬁle, and access to data at any time from any de-

vice connected to the Internet.

But there is always a concern regarding the se-

curity of data stored in the cloud, especially as the

number of constant cyber attacks intensiﬁes. One of

the most promising defenses for the cloud is encryp-

tion, which offers robust protection in both data stor-

age and transit. Encryption is available in two main

security conﬁgurations: client- and server-side.

With server-side encryption, the cloud storage

provider manages encryption keys along with their

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

data, and many cloud storage providers use this

method. This limits the complexity of the environ-

ment while maintaining the isolation of your data, but

there are several risks of keeping the encryption key

and data encrypted by it in the same place. In ad-

dition, the cloud provider itself can access keys and

hence data in plain text.

In client-side encryption, the user is responsible

for keeping their keys, accessed with a password,

which is a user-centric approach to keep control of

the data. This conﬁguration limits the risk of external

access to sensitive information, by unauthorized en-

tities, since encryption is ideal for conﬁdential data.

Most client-side encryption methods involve encrypt-

ing data for storage in a cloud service that does not

support natively.

The user can determine which data to encrypt and

which data to store in the cloud in plain text. The

user can encrypt only certain ﬁles, or create an entire

encrypted ﬁle container or storage folder. This can

be done even when using server-side encryption ser-

vices, adding an extra layer of security to extremely

sensitive data.

2.2 Disk Encryption

Many people and companies have sensitive informa-

tion stored on the most diverse types of devices. In

this context, Full Disk Encryption (FDE) has emerged

as a solution to ensure the security of these infor-

mation in cases of theft or loss of devices that store

them, since mechanisms such as passwords and bio-

metric blocking do not prevent the storage media from

being accessed when installed on another machines.

FDE is an effective method of protecting data from

unauthorized access, because it consists of encrypt-

ing entire volumes/partitions or disks, ensuring that

information can not be accessed without the mech-

anism and key used for encryption. Existing mecha-

nisms can be classiﬁed into ﬁrmware-level encryption

(hardware-based solutions) and kernel-level encryp-

tion (software-based solutions).

Hardware-based FDE engines are called Self-

Encrypting Drives (SEDs), in which encryption is

performed by the disk controller and the encryption

keys are not present in the CPU neither in the main

memory of the computer. In addition, the MBR (Mas-

ter Boot Record) is also encrypted, preventing manip-

ulation attacks. This type of FDE is present in some

speciﬁc storage media models, such as Intel SSD 320

and 520 drives, and requires a previous boot envi-

ronment with a screen available for entering the ac-

cess password. According to (Meijer and van Gas-

tel, 2019), some Solid State Drive (SSD) models have

failures in the encryption process, allowing the stored

data to be extracted from the drive without knowing

the key used to perform the encryption.

Software-based FDE engines are applications run

at the kernel level by the CPU, in which data and

used keys are stored in the main memory. This type

of FDE consists of intercepting all operating system

(OS) requests and encrypting the data before stor-

age, or fetching encrypted data on storage media and

returning OS-readable information. Software-based

FDE do not encrypt the MBR, which allows manipu-

lative attacks on it. This kind of solution has been on

the market since the 2000s, beginning with the launch

of Cryptoloop (H

olzer, 2004) for Linux, which was

the predecessor of Dm-Crypt (Broz, 2015), released

in 2003.

Linux based operating systems commonly imple-

ment the LUKS (Linux Uniﬁed Key Setup) disk-

encryption speciﬁcation. LUKS is a platform-

independent standard on-disk format based on a two

level key hierarchy, protecting the master key using

PBKDF2 (Network Working Group, 2000) as key

derivation function, with an anti-forensic splitter (AF-

splitter) to solve the problem of data remanence, that

inﬂates and splits the master key before storing it on

disk (Fruhwirth, 2011; Bossi and Visconti, 2015).

In addition to these, other disk encryption sys-

tems are also widely used by end users, such as Cryp-

tomator, that uses a virtual ﬁle system to create a ﬁle

container, where the encrypted data are stored (Cryp-

tomator, 2019).

2.3 Intel SGX

Intel SGX technology compiles a set of instructions

and mechanisms for creating and accessing a pro-

tected region of memory, ensuring the conﬁdential-

ity and integrity of sensitive application data. The

ﬁrst version of SGX was added to Intel Core proces-

sors from the 6th generation (Skylake) and allows an

application to start a protected container, called en-

clave. In this context, two signiﬁcant features have

been added in Intel’s x86 architecture: a change in

the enclave memory access and the protection of ap-

plication address mappings (INTEL, 2014; McKeen

et al., 2013).

An enclave is a ﬁxed-size protected area in the ap-

plication’s address space, which allows a portion of

the application code to be run conﬁdentially and se-

curely, ensuring that other software can not access

these information, even if it has high running privi-

lege or if it is running within other enclaves (INTEL,

2014). Attempts to gain unauthorized access to the

contents of an enclave are detected and prevented, or

Secure Cloud Storage with Client-side Encryption using a Trusted Execution Environment

the operation is aborted. While the enclave data are

being processed between the registers and other in-

ternal blocks of the processor, it uses internal access

control mechanisms to prevent unauthorized access to

these data. When data are transferred to main mem-

ory, they are automatically encrypted and stored in a

reserved region, called Processor Reserved Memory

(PRM).

Memory encryption is done using a 128-bit time-

invariant AES-CTR encryption algorithm and con-

taining protections against replay attacks. The en-

cryption key is stored in internal registers of the pro-

cessor, not being accessible to external components,

and is randomly changed at each hibernation or sys-

tem restart event. Memory probes or other techniques

that attempt to modify or replace these data are also

avoided, and the fact of connecting the memory mod-

ule to another system will only give access to the data

in an encrypted form (Aumasson and Merino, 2016;

Intel, 2016).

Intel SGX technology ensures the conﬁdentiality

and integrity of the data while inside an enclave. In

general, when the enclave is destroyed, all informa-

tion is lost. To preserve these information, SGX tech-

nology provides a mechanism that allows the enclave

to seal them using a key called Sealing Key, so the

information can be safely stored on disk. The seal-

ing key is a unique key generated by the CPU for that

enclave and on that particular platform, and it is not

necessary to store it for unsealing the data. Sealing

and unsealing are the operations involved in the data

protection process on disk (INTEL, 2016). The AES-

GCM algorithm is used for data sealing and the AES-

CMAC algorithm is used for key derivation (Aumas-

son and Merino, 2016).

In order to share information, protected in a run-

ning enclave, with other enclaves, the security must

be ensured at the destination and also during the trans-

mission process. To this end, Intel SGX technology

provides a feature called attestation, which allows an

enclave to prove to third parties that it is legitimate,

unadulterated and correctly loaded, allowing the cre-

ation of a secure channel for communication between

them. Intel SGX technology provides mechanisms

that enable two forms of attestation: local attestation

and remote attestation (INTEL, 2016).

Local attestation is performed when two enclaves

on the same device need to securely exchange infor-

mation with each other. In this case, one enclave must

prove its identity and authenticity to the other in order

to begin the communication. This form of attestation

uses a symmetric key system, with the enclave asking

the hardware a credential, which should be forwarded

to the other enclave who will verify that the credential

was generated on the same platform. The used key is

embedded in the hardware platform, and only known

by the enclaves running on that platform.

Remote attestation is performed when enclaves

are running on separate devices and need to securely

exchange information with each other or when a third

party needs to securely send data to an enclave. This

form of attestation requires the use of asymmetric

encryption, a special Intel-provided enclave called

the Quoting Enclave, and a CPU-produced creden-

tial called QUOTE. The QUOTE credential is gener-

ated by replacing the Message Authentication Code

(MAC) of the reports generated by local enclaves with

a signature created using an asymmetric key using

the Intel Enhanced Privacy ID (EPID). To ensure the

security of the Intel EPID key, only the instantiated

Quoting Enclave has access to it (Anati et al., 2013;

INTEL, 2016).

3 RELATED WORK

This Section contains related works that also consider

cloud storage security and privacy, and disk encryp-

tion using the Intel SGX technology.

3.1 Cloud Storage Security and Privacy

The security and privacy of ﬁles stored in the cloud

are a central concern because such data are being de-

livered to third parties. Several works in the litera-

ture present different techniques and mechanisms to

guarantee or increase the security of users’ ﬁles and

maintain their conﬁdentiality.

One of the features widely used by cloud storage

providers to improve storage utilization is deduplica-

tion, which aims to eliminate duplicate copies of re-

peating data. Deduplication can also optimize the net-

work data trafﬁc by reducing number of bytes that

must be sent, but can also be used as a side chan-

nel technique by attackers who try to obtain sensi-

tive information of other users’ data. In order to miti-

gate this vulnerability, client-side encryption schemes

are proposed that allow data deduplication and audit

while prevent leakages (Shin and Kim, 2015; Youn

et al., 2018).

Audit operations can also characterize a point of

failure, allowing encryption key exposure. To deal

with this problem, in (Yu and Wang, 2017), the au-

thors point out that cloud storage auditing scheme

with key-exposure resilience has been proposed, but

valid authenticators can still be forged later than the

key-exposure time period, if the current secret key of

the data owner has been obtained. Then, the authors

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

propose a new kind of cloud storage auditing and de-

sign a concrete scheme where the key exposure in one

time period does not affect the security of cloud stor-

age auditing in other time periods.

A relationship between secure cloud storage and

secure network coding is also demonstrated by (Chen

et al., 2016), what originates a systematic way to con-

struct secure cloud storage protocols based on any se-

cure network coding protocol. The authors also pro-

pose a publicly veriﬁable secure cloud storage proto-

col that support user anonymity and third-party public

auditing.

Also, (Gopinaath and Kiruthika, 2017) presents a

server-side encryption approach with federation shar-

ing for cloud storage using a hybrid environment. An

approach to split the data and distribute them along

different cloud servers is described in (Li et al., 2017),

to prevent cloud service operators from directly ac-

cessing partial data. The authors also present an alter-

native approach to determine whether the data packets

need a split to shorten the operation time.

Hardware-based security mechanisms are also

used to provide security and privacy in cloud storage

services. In (Crocker and Querido, 2015), the authors

describe a two factor encryption architecture that in-

corporates the use of a hardware token. A proof of

concept was developed with a middleware that can be

used with any cloud storage provider that makes use

of the OAuth 2.0 protocol for authentication and au-

thorization.

In (Valadares et al., 2018), Trusted Execution En-

vironments (TEEs) are proposed to increase the se-

curity and privacy of data storage and processing in

cloud/fog-based IoT applications. The authors pro-

pose an architecture that applies authentication and

authorization for the participants, and cryptography

for the generated data. These data must be decrypted

and processed only inside a TEE application. A proof

of concept using Intel SGX was implemented and

evaluated, presenting an acceptable communication

latency when compared to an application that did not

apply any security mechanism.

3.2 Disk Encryption with Intel SGX

Intel SGX technology has been used in a wide range

of applications and in several areas. One of these ar-

eas is disk encryption, in which Intel SGX provides an

additional layer of security for the storage of sensitive

ﬁles.

In (Richter et al., 2016) the authors introduce the

concept of isolating kernel components from the oper-

ating system into enclaves in order to prevent vulner-

abilities in certain modules from completely compro-

mising the system. Due to the restrictions of the Intel

SGX technology, the enclave can not be executed di-

rectly by the kernel, so the authors had to include a

daemon running in user mode to communicate with

a Loadable Kernel Module (LKM). As proof of con-

cept, the authors created an LKM that registers a new

mode inside the kernel encryption API (Application

Programming Interface), allowing to carry out the en-

cryption process within an enclave, that can be used

for disk encryption.

The proposal presented by (Burihabwa et al.,

2018) is to include the data encryption within a

ﬁle system based on the FUSE

(Filesystem in

Userspace), using the Intel SGX technology to ensure

that the stored data are secure. File requests made to

the operating system through the virtual ﬁle system

are intercepted by the FUSE library and sent to an en-

clave, which performs the process of encrypting and

decrypting the data using the native data sealing fea-

ture provided by the Intel SGX technology.

The paper (Ahmad et al., 2018) focuses on de-

creasing the chances of success in a side channel at-

tack on a ﬁle system based on the Intel SGX technol-

ogy. It consists of a library that has a ﬁle system run-

ning within an enclave, and an application running in

another enclave making requests to that ﬁle system.

Communication between the enclave library and the

enclave application is performed through a queue of

messages sent by encrypted communication channels

between the processes.

4 CLIENT-SIDE ENCRYPTION

USING TEE

This work proposes the inclusion of the data sealing

feature, provided by the Intel SGX technology, inte-

grated to a Disk/File Encryption Tool. In order to

validate our proposal, we are considering the Cryp-

tomator software. Cryptomator works with ﬁle con-

tainer encryption, providing the user’s operating sys-

tem with a virtual ﬁle system where data are read and

written elsewhere.

Cryptomator is designed to be used as a client-side

ﬁle encryption service and can work with any cloud

data synchronization software (Horalek and Sobeslav,

2018). In addition, Cryptomator provides the user

with a transparent service by encrypting the ﬁles indi-

vidually, allowing the cloud storage service to main-

tain a ﬁle update history. Another feature provided by

Cryptomator is directory structure obfuscation (Cryp-

tomator, 2019).

https://github.com/libfuse/libfuse

Secure Cloud Storage with Client-side Encryption using a Trusted Execution Environment

The application is divided into three main mod-

ules, namely:

• Cryptomator: graphical interface that provides

the user with control of the containers;

• CryptoFS: library that implements a virtual ﬁle

system and is responsible for reading and writing

data within the containers, through the operating

system, providing the ﬁle system with decrypted

data and encrypting the received data before stor-

ing them on a secondary media;

• CryptoLib: library that provides functions for the

encryption and decryption of the ﬁles, which are

handled by the CryptoFS module.

The process of reading the ﬁles provided by the

application can be described in 12 steps, as shown in

Fig. 1. These steps are explained below:

1. The user requests the operating system to open a

ﬁle;

2. The operating system requests FUSE for ﬁle data.

FUSE allows the userspace applications export a

ﬁlesystem to the Linux kernel, with functions to

mount the ﬁle system, unmount it and communi-

cate with kernel;

3. FUSE forwards this request to the Cryptomator,

using the CryptoFS library;

4. Cryptomator requests the operating system to

have the ﬁle data fetched from the storage device;

5. The operating system locates the data;

6. These data are loaded into the main memory;

7. The operating system provides these data to the

Cryptomator;

8. The CryptoFS library sends the encrypted data to

the CryptoLib library;

9. The CryptoLib library decrypts the received data

and returns them to CryptoFS library;

10. The CryptoFS library sends the decrypted data to

FUSE;

11. FUSE forwards such data to the operating system;

12. Finally, the operating system provides the user

with the decrypted ﬁle.

The data writing process is similar to the reading

process, but with the plain data being sent to the Cryp-

toLib library before, and then they are forwarded to

the operating system for recording in the storage de-

vice. The ﬁles stored in the local device are also syn-

chronized with a cloud storage service, already in en-

crypted form, and a second layer of encryption can be

applied by the cloud storage provider.

Cryptomator

CryptoLib

Operating

System

Storage Device with Cloud Synchronization

Virtual File

System

Cryptomator

CryptoFS

User

1 2

810

12 11

Figure 1: Workﬂow for Reading and Decrypting Stored

Data with Cryptomator.

In this sense, we propose to include the data seal-

ing mechanism provided by Intel SGX technology

within the CryptoLib library, in parallel with the ex-

isting AES encryption, and to change the CryptoFS

library to use this modiﬁed implementation. The pro-

posed change ensures, through the use of existing

AES encryption, that the CryptoLib library can still

be used in environments where Intel SGX technology

is not available, thereby maintaining project compati-

bility with changes in the main design.

5 PROOF OF CONCEPT

Cryptomator is designed to support multiple encryp-

tion modes, without any of them affecting the im-

plementation of the others or requiring changes to

the main project to support them. The CryptoLib li-

brary is composed of a Java interface (API), which de-

scribes all the classes and methods that each encryp-

tion mode must implement to be used by the software,

and an implementation of the AES encryption based

on the described interface, which is called v1 within

the library.

Our implementation consists of creating a new

mode called sgx, implementing all classes and meth-

ods requested by the library interface, and changing

the CryptoFS library to use sgx mode instead of v1.

It was also necessary to create a C++ library for com-

munication with the SGX enclaves, called SgxLib.

The sgx mode has a Java class with 4 main meth-

ods used by all other classes of the mode, namely:

• InitializeEnclave: Handles the initialization of

the SGX enclave;

• SgxEncryptBytes: Encrypts an array of bytes;

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

• SgxDecryptBytes: Decrypts an array of bytes;

• DestroyEnclave: Destroys the enclave when it is

no longer needed.

These 4 methods are only used to invoke the cor-

responding methods within the SgxLib library. In or-

der to handle the communication between Java meth-

ods and the SgxLib library, it was necessary to create

a Java Native Interface (JNI), containing the 4 main

methods of the Java class. This interface has the pur-

pose of receiving the Java application data, converting

them to the C++ language, performing the process im-

plemented by the method and then converting its re-

sults and sending them to Java.

Fig. 2 describes the process of sending and receiv-

ing data between CryptoFS and CryptoLib libraries,

which includes two additional steps for communica-

tion between the CryptoLib library and the SGX en-

clave. The shaded box indicates a trusted execution

environment (SGX in this case), where the key is ma-

nipulated and the data are encrypted and decrypted.

The communication ﬂow is explained below:

1. CryptoFS library calls encrypt/decrypt functions

in CryptoLib library, which contais AES and SGX

modes;

2. In SGX mode, CryptoLib library creates an en-

clave and sends to it each data block to perform

the encrypt/decrypt process;

3. Encrypt/decrypt blocks are send back to Cryp-

toLib;

4. Encrypt/decrypt data forward to CryptoFS library.

Cryptomator

CryptoLib

Cryptomator

CryptoFS

SGX Mode

Enclave SGX

AES Mode

Figure 2: Workﬂow Performed for Data Encryption and

Decryption through the Cryptomator with the Inclusion of

Data Sealing Feature Provided by Intel SGX Technology.

6 PERFORMANCE EVALUATION

To evaluate the proposal based on the implemented

proof of concept, performance tests were carried out

comparing four modes of data storage, and are as fol-

lows:

• Without Encryption: Data read and write oper-

ations on storage media without any type of en-

cryption;

• LUKS: Data read and write operations on storage

media using native cryptographic mode in Ubuntu

with LUKS (Linux Uniﬁed Key Setup);

• Cryptomator: Data read and write operations on

the storage media using the original Cryptomator

application;

• Cryptomator-SGX: Data read and write opera-

tions on the storage media using the implemented

solution, which integrates the SGX data sealing

with the Cryptomator application.

For each mode described above, four different

tests were performed, two for data read operations and

two for data write operations. The tests considered the

transferring of a single ﬁle and also multiple ﬁles in

sequence. For the task, the DVD ISO image of the

CentOS 7 operating system (CentOS, 2019), which

has a size of 4.27 GB, was used as the data set for

the single ﬁle transfer, as well as the ﬁles and folders

obtained when extracting the same image, using the

recursive transfer of directories, were used character-

izing the transfer of several ﬁles.

The RSync (Ubuntu, 2012) tool was used to per-

form data transfer, using -avhh modes for single ﬁle

and -rvhh for multiple ﬁles (directories as execution

parameters). Further details on the parameters used

are outlined below:

• -a: Single ﬁle copy mode;

• -r: Recursive copy mode of directories, in which

all sub-directories and ﬁles are copied too;

• -v: Option to print what is running at the com-

mand prompt;

• -h: Mode to display a better format to read num-

bers. This causes large numbers to avoid us-

ing larger units, considering a sufﬁx K, M, or G.

With this option speciﬁed once, these units are K

(1000), M (1000 * 1000) and G (1000 * 1000

* 1000); with this option repeated, the units are

powers of 1024 instead of 1000.

6.1 Experimental Setup

Tests were run in custom PC, motherboard with a

Z390 chipset, 16 GB 2666 MHz RAM, SGX enabled

with 128 MB PRM size, running Ubuntu 16.04.6 LTS,

kernel 4.15.0-51-generic. Intel TurboBoost, Speed-

Step, and HyperThread extensions were disabled, to

Secure Cloud Storage with Client-side Encryption using a Trusted Execution Environment

get stable results. We used the Intel SGX SDK 1.7 for

Linux and set the stack size at 4 KB and the heap size

at 1 MB.

In order to measure the CPU contribution to the

performance impact of the encryption task, two dis-

tinct CPUs were used:

• CPU 1: Dual-core 3.8 GHz Intel Pentium G5500;

• CPU 2: Octa-core 3.6 GHz Intel i7 9700K.

We also used three distinct storage devices to per-

form the tests, each one containing different charac-

teristics regarding performance for data reading and

writing:

• Device 1: HDD Samsung ST1000LM024, 1 TB

storage size, 5400 RPM spin speed, 145 MB/s

maximum data transfer rate, 8 MB buffer DRAM

size;

• Device 2: SSD SanDisk PLUS, 240 GB storage

size, 530 MB/s sequencial read, 440 MB/s se-

quencial write;

• Device 3: SSD NVMe M.2 Samsung 970 EVO

Plus, 250 GB storage size, 3500 MB/s sequencial

read, 2300 MB/s sequencial write.

In all devices, an Ext4 ﬁle system partition was

used. Since one of the storage devices has high per-

formance (SSD M.2), and the highest performance

in a data transfer between two devices is deﬁned by

the medium with lower performance, a RAMDisk was

used to perform the recording tests, as data source and

target for the read tests. This way, there was no speed

limitation by the source or destination of the data.

Each test was performed 10 times, aiming to ob-

tain the average transfer rate in each scenario consid-

ered. Another set of tests was also performed to anal-

yse the reading performance of data previously stored

in each of the devices. The single ﬁle reading and a

set of different ﬁles were tested.

6.2 Results and Discussion

The results obtained in the single ﬁle read, on the

three storage devices using the Intel Pentium G5500

CPU, can be seen in Fig. 3. The performance of

Cryptomator-SGX solution is higher than its origi-

nal implementation, with the exception of the hard

disk, where the throughput was slightly below that

observed in the unmodiﬁed Cryptomator implemen-

tation, but still very close to that. It is also observed

that, in this scenario, the proposed solution obtained

transfer rates very close to or even above those pre-

sented by LUKS, except in storage device M.2.

Similarly, the results obtained using the Intel Core

i7 9700K CPU, for the three storage devices consid-

ering a single ﬁle read, can be seen in Fig. 4. In

100

200

300

400

500

HD SSD M.2

Transfer Rate (MB/s)

Storage Device

Without Encryption

16.08

451.96

498.69

LUKS

9.26

145.33

353.21

Cryptomator

9.47

118.32

118.64

Cryptomator-SGX

9.22

185.31

209.72

Figure 3: Transfer Rate Reading a Single File with Intel

Pentium G5500 CPU.

this scenario, the Cryptomator application achieved

throughput rates close to or higher than LUKS, with

the Cryptomator-SGX solution achieving better per-

formance than both in the three storage devices tested.

100

200

300

400

500

HD SSD M.2

Transfer Rate (MB/s)

Storage Device

Without Encryption

16.57

447.58

498.69

LUKS

9.25

187.09

115.54

Cryptomator

9.35

172.81

223.06

Cryptomator-SGX

9.43

230.66

272.68

Figure 4: Transfer Rate Reading a Single File with Intel

Core I7 9700K CPU.

When considering the reading of multiple and dif-

ferent ﬁles, using the Intel Pentium G5500 CPU, the

good performance of the proposed solution is also

noted, except in the use of the SSD storage device,

in which a drop of about 15% in the transfer rate was

obtained, as shown in Fig. 5.

100

200

300

400

500

HD SSD M.2

Transfer Rate (MB/s)

Storage Device

Without Encryption

15.25

242.01

460.17

LUKS

9.15

98.21

324.54

Cryptomator

7.28

87.47

110.67

Cryptomator-SGX

8.44

74.92

176.07

Figure 5: Transfer Rate Reading Multiple Files with Intel

Pentium G5500 CPU.

Using the Intel Core i7 9700K CPU, the

Cryptomator-SGX solution outperforms the original

application on all three storage devices tested, when

reading multiple ﬁles, as showed in Fig. 6.

In order to evaluate the Cryptomator-SGX per-

formance on writing operations, we repeat the previ-

ous tests, but reading data from RAMDisk and writ-

ing in the storage device. The ﬁrst analysis per-

formed concerns the single ﬁle recording using the

Intel Pentium G5500 CPU, with results presented in

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

100

200

300

400

500

HD SSD M.2

Transfer Rate (MB/s)

Storage Device

Without Encryption

15.62

317.12

447.02

LUKS

9.14

157.85

105.86

Cryptomator

7.52

60.42

62.32

Cryptomator-SGX

8.54

95.97

144.97

Figure 6: Transfer Rate Reading Multiple Files with Intel

Core I7 9700K CPU.

Fig. 7. Analyzing these results, we can note that

the transfer modes using the multi-threaded capability

achieved higher transfer rates, relative to Cryptoma-

tor and Cryptomator-SGX, which are limited to using

only one thread.

100

150

200

250

300

350

400

HD SSD M.2

Transfer Rate (MB/s)

Storage Device

Without Encryption

73.36

151.18

373.22

LUKS

56.31

93.16

301.14

Cryptomator

53.34

80.77

88.80

Cryptomator-SGX

53.45

99.35

130.28

Figure 7: Transfer Rate Writing a Single File with Intel Pen-

tium G5500 CPU.

Besides, there is a better performance of the

Cryptomator-SGX solution over the original imple-

mentation of Cryptomator, as the ﬁrst uses the na-

tive cryptographic functions of the processor as well

the execution within the enclave is from native code,

written in C++, and optimized by the compiler. Al-

though the data transfer operations through the JNI

interface, for the communication with the enclave,

and the context changes, generated by the enclave en-

try and exit, have a considerable computational cost,

these two overheads are totally suppressed by the gain

obtained in the data sealing operation.

Fig. 8 presents the results obtained with the In-

tel Core i7 9700K CPU in the same scenario: single

ﬁle writing. As can be seen, Cryptomator and Crypto-

mator-SGX perform signiﬁcantly lower than the other

two modes, because they do not utilize the multipro-

cessing features available on the CPU.

The second data recording analysis considers sev-

eral ﬁles of different sizes, trying to identify the im-

pact caused by the ﬁle system when performing op-

erations to construct the references to such ﬁles. For

this scenario, the ﬁles contained in the previously pre-

sented ISO image were extracted, and all contents

were copied, as already mentioned. The results for

the Intel Pentium G5500 CPU are shown in Fig. 9.

Although the Cryptomator-SGX solution presents

100

150

200

250

300

350

400

450

HD SSD M.2

Transfer Rate (MB/s)

Storage Device

Without Encryption

67.59

141.05

410.37

LUKS

56.60

92.08

355.14

Cryptomator

23.27

18.58

19.32

Cryptomator-SGX

44.05

37.44

58.86

Figure 8: Transfer Rate Writing a Single File with Intel

Core I7 9700K CPU.

100

150

200

250

300

350

400

450

HD SSD M.2

Transfer Rate (MB/s)

Storage Device

Without Encryption

66.61

115.84

434.63

LUKS

57.54

103.30

341.95

Cryptomator

11.13

30.64

56.97

Cryptomator-SGX

9.29

29.85

36.62

Figure 9: Transfer Rate Writing Multiple Files with Intel

Pentium G5500 CPU.

a substantial performance overhead when using the

M.2 storage device, the transfer rates achieved were

close to 80% when compared directly to the original

Cryptomator implementation.

Fig. 10 presents the results obtained using the

Intel Core i7 9700K CPU for multiple ﬁles writing.

In this scenario there is a considerable decrease in

performance, both in the original implementation of

Cryptomator and in the proposed Cryptomator-SGX,

due to the single-thread programming model used by

Cryptomator. Nevertheless, the results obtained with

the use of Cryptomator-SGX show little difference

compared to unmodiﬁed Cryptomator.

100

150

200

250

300

350

400

450

HD SSD M.2

Transfer Rate (MB/s)

Storage Device

Without Encryption

63.09

110.82

399.67

LUKS

54.51

90.52

369.47

Cryptomator

7.81

14.43

16.26

Cryptomator-SGX

7.25

16.72

16.15

Figure 10: Transfer Rate Writing Multiple Files with Intel

Core I7 9700K CPU.

7 SECURITY EVALUATION

Another point that users consider when choosing an

application for data encryption is the security it pro-

vides and its vulnerabilities. This section is intended

to present the threat model, the security analysis of

Secure Cloud Storage with Client-side Encryption using a Trusted Execution Environment

Intel SGX technology and the security analysis of the

implemented solution.

7.1 Threat Model

In the threat model we consider that the adversary

aims to access conﬁdential information stored on the

user’s computer hard disk or cloud storage service,

and that he/she has physical access to these platforms

for such task. The attacker can even remove the hard

disk from user’s computer and install it on another

machine with greater computing power, in order to

apply techniques to ﬁnd out the password used in key

generation, or even the encryption key itself. In addi-

tion, it is assumed that the attacker has installed some

malicious software on the user’s computer in order to

obtain the encryption key through a memory dump-

ing, or to obtain the password used to open the con-

tainer by capturing the data entered into the keyboard

through a keylogger.

It is considered that Intel SGX technology works

properly and according to its speciﬁcations, and that

the proposed solution development environment is re-

liable.

7.2 Intel SGX Technology Security

Evaluation

To build a system that is considered secure, the

Trusted Computing Base (TCB) should be kept as

small as possible in order to reduce the chances of

success in an attack. In Intel SGX technology, the

TCB is composed of the CPU and its internal ele-

ments, such as hardware logic, microcode, registers

and cache memory, and some software elements used

in remote attestation, such as quoting enclave.

In the implemented solution, the responsibility of

the data encryption was delegated entirely to the en-

clave. Thus, all warranties provided by the Intel SGX

technology are in use during data encryption. Some

of these guarantees are:

• The cryptographic key never goes outside the pro-

cessor boundaries;

• The memory in which it is running, PRM, is en-

crypted and has mechanisms against direct mem-

ory attacks;

• Protection against external enclave attacks, even

if these attacks come from components with high

execution privilege, such as BIOS or hypervisor,

as speciﬁed in Section 2.3.

However, even though the Intel SGX technology

have multiple data protection mechanisms, there are

some forms of attacks that it is susceptible to. In-

tel documentation lists technology limitations, speci-

fying that SGX is unable to prevent side-channel at-

tacks, exploiting cache and data access patterns, or

physical attacks against the CPU such as fault injec-

tion or reprogramming of machine code functional-

ities (Brasser et al., 2017; Wang et al., 2017; Chen

et al., 2018).

The Intel SGX technology is also susceptible

to the speculative execution attack, called Spectre

(Kocher et al., 2019). The exploitation of Spectre vul-

nerabilities to infer secrets contained in an enclave

is demonstrated by (Chen et al., 2019), where the

authors show that an enclave’s code execution pre-

diction could be inﬂuenced by applications outside

the enclave, which could temporarily change enclave

control ﬂow to execute instructions that lead to ob-

servable cache state changes, and, thus, an adversary

can use to learn secrets from the enclave memory or

its registers.

One of these problems was addressed by (Ah-

mad et al., 2018), in which the authors propose a

way to reduce the chances of success in a syscall

and page fault-based side channel attacks by using an

ORAM protocol in conjunction with the Intel SGX.

But both side-channel and speculative execution at-

tacks are complex to perform practically.

In addition to the vulnerabilities described by In-

tel, an SGX enclave may be compromised in cases

where the enclave development environment has been

compromised, or if the SDK used is not the newest

version provided by Intel through its ofﬁcial channel.

Enclave security also depends on the developer, since

the developer must take precautions when manipulat-

ing data within the enclave, thus avoiding problems

with data leaks when manipulating pointers or calls

outside the enclave.

7.3 Cryptomator-SGX Solution

Security Evaluation

In order to validate the security of the implementa-

tion, the Intel SGX technology was considered as se-

cure, being validated only the change made in the

Cryptomator.

When considering that the Intel SGX technology

is secure, it is guaranteed that the data can only be

decrypted on the platform where it was encrypted,

or if the attacker is able to obtain the decryption key

through a brute-force attack. In this scenario, we must

ensure that only the data owner has access to them on

the platform where they were encrypted, so the pass-

word used to open the container has been maintained

and is used to encrypt the ﬁles name.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

In this way, even if an attacker gains physical ac-

cess to the media and the platform used, he/she will

still need the password to access the data. If he/she

does not have access to the platform, he/she will need

the user’s password and also the key used by the en-

clave to encrypt the data. In a computer memory at-

tack, the key used by the enclave will not be available

since it never goes beyond the processor limits. How-

ever, with this attack mode, it is possible to obtain the

password used by the user to open the container.

This scenario also ensures data conﬁdentiality

even if the cloud storage provider is compromised as

data sent to it are previously encrypted on the user’s

local platform. The client-side encryption, allied with

the encryption provided by the cloud storage provider,

adds an extra layer of security to user data and repre-

sents a new obstacle for the attacker to overcome.

Due the Cryptomator software is developed in

Java and is separated into three main modules, an at-

tacker can make use of the CryptoLib library and im-

plement its own solution and bypass existing security

mechanisms within Cryptomator. Thus, a second se-

curity layer is necessary in the CryptoLib, in order to

authenticate the request to open the sealed data. This

proposal is set out in future work.

8 LIMITATIONS OF THE

SOLUTION

The solution implemented consists in encrypting only

the data of the ﬁles that are stored inside the container

created through the application. Because of this, some

limitations were identiﬁed in the application.

Because data sealing adds 560 bytes per encrypted

block, since it includes authentication data (AES-

GCM), the ﬁnal ﬁle size within the container will al-

ways be larger than the original ﬁle size. Thus, the

deployed solution always use more disk space for the

same ﬁles over other storage modes. As 32KB size

blocks are used, the ratio of ﬁle size increase is about

1.7%.

To perform the encryption process for each ﬁle,

Cryptomator stores a ﬁle with encrypted name inside

the container, which corresponds to the source ﬁle. In

this scenario, the implemented solution could not be

used to encrypt the name of the ﬁles inside the con-

tainer by an operating system limitation, as Linux sys-

tems impose a maximum ﬁlename length of 255 char-

acters for most ﬁlesystems and sealing the ﬁlename

would add 560 bytes to it. To circumvent this limi-

tation, the ﬁle name encryption was maintained using

the existing AES mode, with the key generated from a

password chosen by the user. This limitation eventu-

ally added an extra layer of protection in the solution

by preventing the opening of the container data, on

the platform where data were encrypted, without the

user’s password being informed.

The limitation that has been addressed in Section

6 regarding application performance is due to the fact

that it uses only one core for processing. Because of

this, only one enclave is used in the process of en-

cryption and decryption of the data, reducing the per-

formance of the system. Another point analyzed was

the constant need to convert the data between the Java

language and the C++ language through the JNI in-

terface, generating a high cost of processing. Chang-

ing the architecture of the solution to make better use

of available resources within the system will be the

subject of future work. However, the need for conver-

sion between languages can not be removed due to the

need to use native code to execute the SGX enclave.

Sealing the data using the sealing key can cause

inconvenience, since the data will only be accessible

if the application is executed through the processor

that was used for sealing them. One way to circum-

vent this limitation is to create a mechanism within

the application for secure data transfer between two

platforms on which it is running, allowing remote ac-

cess and data backup whenever necessary. If the pro-

cessor used to seal the data is lost in the event of a

malfunction or other occurrence, the data cannot be

unsealed either, as the sealing key is derived from a

unique processor key. This requires mechanisms to

securely back up data to be read on another platform

or to use another key derivation scheme. Such mech-

anisms will also be subject of future work.

Using sealing key also makes ﬁle sharing difﬁcult

through the cloud storage provider. Such a situation

can also be circumvented by using remote attestation,

or by using another CPU-independent key derivation

scheme for ﬁle encryption. Finally, the proposed solu-

tion, as well as client-side encryption itself, may hin-

der the application of current data deduplication tech-

niques, being necessary to deploy mechanisms in con-

junction with the cloud storage provider, as described

in (Yan et al., 2018).

9 CONCLUSION AND FUTURE

WORK

This work proposed the use of Intel SGX technology

for data encryption in an open-source software, to add

an extra layer of security to data stored at a cloud stor-

age provider, ensuring data conﬁdentiality even if the

storage server leak the data.

From the performance analysis presented in Sec-

Secure Cloud Storage with Client-side Encryption using a Trusted Execution Environment

tion 6, we have identiﬁed that, in most cases, the

implemented solution has achieved superior perfor-

mance compared to the original application for both

data read and write. The increase in performance can

be attributed to the fact that the encryption process

was carried out directly by the processor, while in

the original application it was run through the Java

Virtual Machine. When comparing the solution with

the multithreading solutions, we have identiﬁed that

the implemented solution and the original applica-

tion have much lower performance on high perfor-

mance media, indicating a limitation on the part of

the project implementation.

Considering the security guarantees provided by

Intel SGX technology, which are described in Sec-

tion 2.3, the developed solution offers an extra level

of security by sealing the data using the sealing key

in conjunction with the user’s password to open the

containers. Thus, in an attack on the encrypted data,

the attacker will need to discover the user’s password,

and also the sealing key or gain physical access to the

processor used for sealing.

In order to avoid that a user’s password can be ob-

tained in a memory attack, it is necessary to change

the software so that the password is stored inside the

enclave and does not leave its limits. Just as it was

possible to seal user ﬁle data using Intel SGX technol-

ogy, it can also seal conﬁguration data. Such change

requires adjustments to the structure of the CryptoFS

library and may remove compatibility with the main

project, and it will be the subject of future work.

Also, it is possible to use a similar approach to

(Richter et al., 2016), encrypting the data within the

boundaries of the enclave, but using a derived key

from an user password, and manipulating that key

only within the enclave. Such approach makes the

data decryption independent of the processor that

encrypted them. Also, the current solution can be

changed to use the remote attestation feature and al-

low container data transfer between two machines

running the application over secure channels.

Finally, better performance can be achieved by

using all processing cores available on the platform.

Such implementation demands a change in the main

structure of the application, which treats the requests

coming from the operating system, being necessary to

add the use of queues and parallel processing, thus al-

lowing one block to be processed by the enclave while

another is read or written to the storage device.

The source code of the presented solution

is available at https://github.com/utfpr-gprsc/

cryptomator-sgx.

REFERENCES

Ahmad, A., Kim, K., Sarfaraz, M. I., and Lee, B. (2018).

Obliviate: A data oblivious ﬁle system for Intel SGX.

In Proceedings of the 25th Network and Distributed

System Security Symposium, San Diego, CA, USA. In-

ternet Society.

Anati, I., Gueron, S., Johnson, S., and Scarlata, V. (2013).

Innovative technology for CPU based attestation and

sealing. In Proceedings of the 2nd International Work-

shop on Hardware and Architectural Support for Se-

curity and Privacy, Tel-Aviv, Israel. ACM.

Aumasson, J.-P. and Merino, L. (2016). SGX secure en-

claves in practice: Security and crypto review. In Pro-

ceedings of the Black Hat, Las Vegas, NV, USA. Black

Hat.

Bossi, S. and Visconti, A. (2015). What users should

know about full disk encryption based on LUKS. In

Proceedings of the 14th International Conference on

Cryptology and Network Security, Marrakesh, Mo-

rocco. Springer.

Branscombe, M. (2015). Has microsoft been looking at user

ﬁles to ﬁnd the 75tb onedrive hoarders?

Brasser, F., M

uller, U., Dmitrienko, A., Kostiainen, K.,

Capkun, S., and Sadeghi, A.-R. (2017). Software

Grand Exposure: SGX cache attacks are practical. In

Proceedings of the 11th USENIX Workshop on Offen-

sive Technologies, Vancouver, BC, Canada. USENIX.

Broz, M. (2015). DMCrypt.

https://gitlab.com/cryptsetup/cryptsetup/-

/wikis/DMCrypt.

Burihabwa, D., Felber, P., Mercier, H., and Schiavoni, V.

(2018). SGX-FS: Hardening a ﬁle system in user-

space with Intel SGX. In Proceedings of the 10th

IEEE International Conference on Cloud Computing

Technology and Science, Nicosia, Cyprus. IEEE.

CentOS (2019). CentOS Project. https://www.centos.org/.

Chen, F., Xiang, T., Yang, Y., and Chow, S. S. (2016). Se-

cure cloud storage meets with secure network coding.

IEEE Transactions on Computers, 65(6).

Chen, G., Chen, S., Xiao, Y., Zhang, Y., Lin, Z., and Lai,

T. H. (2019). SgxPectre: Stealing Intel secrets from

SGX enclaves via speculative execution. In Proceed-

ings of the 4th IEEE European Symposium on Security

and Privacy, Stockholm, Sweden. IEEE.

Chen, G., Wang, W., Chen, T., Chen, S., Zhang, Y., Wang,

X., Lai, T.-H., and Lin, D. (2018). Racing in hyper-

space: Closing hyper-threading side channels on SGX

with contrived data races. In Proceedings of the 39th

IEEE Symposium on Security and Privacy, San Fran-

cisco, CA, USA. IEEE.

Clover, J. (2017). Hackers using icloud’s ﬁnd my iphone

feature to remotely lock macs and demand ransom

payments.

Cox, J. (2016). Hackers stole account details for over 60

million dropbox users.

Crocker, P. and Querido, P. (2015). Two factor encryption

in cloud storage providers using hardware tokens. In

Proc. of the Globecom Workshops, San Diego, CA,

USA. IEEE.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

Cryptomator (2019). Cryptomator system architecture.

https://cryptomator.org/security/architecture.

Fruhwirth, C. (2011). LUKS on-disk format speciﬁcation

version 1.2.3.

Gopinaath, C. and Kiruthika, C. (2017). A server side en-

cryption for cloud storage with federation sharing in

hybrid cloud environment. In Proceedings of the 7th

International Conference on Technical Advancements

in Computers and Communications, Melmaurvathur,

India. IEEE.

olzer, R. (2004). Cryptoloop HOWTO.

https://www.tldp.org/HOWTO/Cryptoloop-HOWTO.

Horalek, J. and Sobeslav, V. (2018). Analysis of the use of

system resources for cloud data security. In Proceed-

ings of the 15th International Conference on Mobile

Web and Intelligent Information Systems, Barcelona,

Spain. Springer.

Huang, K., Siegel, M., and Madnick, S. (2018). Systemat-

ically understanding the cyber attack business: A sur-

vey. ACM Computing Surveys, 51(4).

INTEL (2014). Intel Software Guard Extensions Program-

ming Reference.

INTEL (2016). Intel Software Guard Extensions Developer

Guide.

Intel (2016). Intel Software Guard Extensions SDK for

Linux OS Developer Reference. Intel Corporation.

Khraisat, A., Gondal, I., Vamplew, P., and Kamruzzaman, J.

(2019). Survey of intrusion detection systems: tech-

niques, datasets and challenges. Cybersecurity, 2.

Kocher, P., Horn, J., Fogh, A., Genkin, D., Gruss, D., Haas,

W., Hamburg, M., Lipp, M., Mangard, S., Prescher, T.,

Schwarz, M., and Yarom, Y. (2019). Spectre attacks:

Exploiting speculative execution. In Proceedings of

the 40th IEEE Symposium on Security and Privacy,

San Francisco, CA, USA. IEEE.

Li, Y., Gai, K., Qiu, L., Qiu, M., and Zhao, H. (2017). In-

telligent cryptography approach for secure distributed

big data storage in cloud computing. Information Sci-

ences, 387.

McKeen, F., Alexandrovich, I., Berenzon, A., Rozas, C. V.,

Shaﬁ, H., Shanbhogue, V., and Savagaonkar, U. R.

(2013). Innovative instructions and software model

for isolated execution. In Proceedings of the 2nd In-

ternational Workshop on Hardware and Architectural

Support for Security and Privacy, Tel-Aviv, Israel.

ACM.

Meijer, C. and van Gastel, B. (2019). Self-encrypting de-

ception: weaknesses in the encryption of solid state

drives (SSDs). In Proceedings of the 40th IEEE Sym-

posium on Security and Privacy, San Francisco, CA,

USA. IEEE.

Network Working Group (2000). PKCS #5: Password-

based cryptography speciﬁcation version 2.0.

Onwujekwe, G., Thomas, M., and Osei-Bryson, K.-M.

(2019). Using robust data governance to mitigate the

impact of cybercrime. In Proceedings of the 3rd Inter-

national Conference on Information System and Data

Mining, Houston, TX, USA. ACM.

Pinto, S. and Santos, N. (2019). Demystifying ARM Trust-

Zone: A comprehensive survey. ACM Computing Sur-

veys, 51(6).

PwC (2016). Global economic crime survey 2016: Ad-

justing the lens on economic crime. Technical report,

PwC.

Richter, L., G

otzfried, J., and M

uller, T. (2016). Isolating

operating system components with Intel SGX. In Pro-

ceedings of the 1st Workshop on System Software for

Trusted Execution, Trento, Italy. ACM.

Shin, Y. and Kim, K. (2015). Differentially private client-

side data deduplication protocol for cloud storage ser-

vices. Security and Communication Networks, 8(12).

Singh, M., Singh, M., and Kaur, S. (2019). Issues and chal-

lenges in DNS based botnet detection: A survey. Com-

puters & Security, 86.

Ubuntu (2012). rsync.

https://help.ubuntu.com/community/rsync.

Valadares, D. C. G., da Silva, M. S. L., Brito, A. E. M.,

and Salvador, E. M. (2018). Achieving data dissem-

ination with security using FIWARE and Intel Soft-

ware Guard Extensions (SGX). In Proceedings of the

23th IEEE Symposium on Computers and Communi-

cations, Natal, RN, Brazil. IEEE.

Wang, W., Chen, G., Pan, X., Zhang, Y., Wang, X., Bind-

schaedler, V., Tang, H., and Gunter, C. A. (2017).

Leaky cauldron on the dark land: Understanding

memory side-channel hazards in SGX. In Proceedings

of the 24th ACM SIGSAC Conference on Computer

and Communications Security, Dallas, TX, USA.

ACM.

Weafer, V. (2016). Report: 2017 threats prediction. Techni-

cal report, McAfee Labs.

Yan, H., Li, X., Wang, Y., and Jia, C. (2018). Centralized

duplicate removal video storage system with privacy

preservation in IoT. Sensors, 18(6).

Youn, T.-Y., Chang, K.-Y., Rhee, K.-H., and Shin, S. U.

(2018). Efﬁcient client-side deduplication of en-

crypted data with public auditing in cloud storage.

IEEE Access, 6.

Yu, J. and Wang, H. (2017). Strong key-exposure resilient

auditing for secure cloud storage. IEEE Transactions

on Information Forensics and Security, 12(8).

Secure Cloud Storage with Client-side Encryption using a Trusted Execution Environment