Bảo mật file cho ổ mây ( A file security application for cloud drives )

ACKNOWLEDGEMENTS
We wish to express our sincere thanks to the faculty of Information Technology at
University of Science for providing us with all the necessary facilities not only for the
thesis but also for our whole university life with the faculty.
We are profoundly grateful to Dr. Thai-Son TRAN for his expert, thoroughly
guidance and his continuous encouragement throughout the process of this project to
see that the project rights its target since its commencement to its completion. Those
words may not contain all our gratefulness to his belief in our ability, but by all our
heart, we wish he would always have a good health and an infinite passion to continue
to inspire the next and next student generation as well as have more and more great
researches to make the world better and better.
This is also an opportunity for us to express heartfelt gratitude to all of the Teachers and staff of the Advance Program in Computer Science who helped us directly or
indirectly during the journey of university as well as during the thesis project. Besides, we also wants to give our special appreciation to all professors and instructors
who have convey to us the precious knowledge which is definitely the most important
preparation for us at the entrance of our career in the enormous world of computer
science.
No one has no friend, especially in the time of university, so we want to give our
thanks to all friends, all senior students who have gone through the happiness, the sadness, and even all kinds of difficult situation together with us. We wish them would
always find the success in any thing they desire to do.
Last but not least, we simply just want to express the gratefulness from the bottom
of our heart to our parents , who have always been beside us, taken care of us, given
us the very first important lessons about life since the day we saw this world.
LE SU TRUONG GIANG & CAO KHAC LE DUY

i


TABLE OF CONTENTS
TABLE OF CONTENTS

ii

LIST OF FIGURES

iv

ABSTRACT

vi

1 Introduction
1.1 Objective and Scope . . . . . . .
1.2 Brief description . . . . . . . . .
1.2.1 Device-based Encryption .
1.2.2 Authorization Mechanism
1.2.3 Backup Mechanism . . . .
1.2.4 Extendability . . . . . . .
1.2.5 Files management . . . . .
1.3 Related Works . . . . . . . . . .

.
.
.
.
.
.
.
.

.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

1
2
4
4
4

5
6
7
7

2 Background
2.1 Server-side Development . . . . . . . . . . . .
2.1.1 Representational State Transfer . . . . . .
2.1.2 Python and Flask Framework . . . . . . .
2.2 Client-side Development . . . . . . . . . . . .
2.2.1 Android and the basic knowledge . . . .
2.2.2 Client Cloud Drive APIs . . . . . . . . .
2.2.3 Local Area Network (LAN) Server . . . .
2.2.4 ReactJS in Web Development . . . . . .
2.3 Cryptography . . . . . . . . . . . . . . . . . .
2.3.1 RSA Algorithm . . . . . . . . . . . . . .
2.3.2 Advanced Encryption Standard Algorithm
2.3.3 AES and RSA Combination . . . . . . .
2.4 Multi-step Authentication . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.

.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

9
9
9
11
14
14
17
18

19
21
21
24
26
28

.
.
.
.
.
.
.

32
32
33
52
56
56
57
60

.
.
.
.
.
.

.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

3 Methodology
3.1 Front-end Development . . . . . . . . .
3.1.1 Android Mobile Application . . .
3.1.2 Web Application . . . . . . . . .
3.2 Device-based Cryptography . . . . . . .
3.2.1 Unique and Non-unique Identifiers
3.2.2 Multiple Device . . . . . . . . . .
3.3 Authorization . . . . . . . . . . . . . .
ii

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.

.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.

.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.

.
.
.
.
.
.

.
.
.
.
.
.
.


4 Results

63

5 Conclusions

69

6 Future Works
6.1 Platforms . . . . . . . . . . . . . .
6.2 Performance Optimization . . . . .
6.3 Features Addition and Modification .
6.4 UI/UX Refining . . . . . . . . . . .
6.5 Satellite Application . . . . . . . . .

71
71
71
72
73
73

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.

.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.

.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.

.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.

.

APPENDICES

74

A Google and its Drive API

74

B Dropbox and its API

77

C Android Activity and Fragment Lifecycles

79

D React Componnent Lifecycle

80

REFERENCES

89

iii


LIST OF FIGURES

1.1 The mobile OS market shares in Quarter 3 of 2016 [1] . . . . . . . . .
1.2 Shares of cloud drive service for SMBs.[2] . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7

16-byte matrix of each plain-text block . . . .
Bytes Substitution Step of each AES rounds .
Row Shifting Step of AES . . . . . . . . . .
Columns Mixing Step of AES . . . . . . . . .
Key Addition Step of AES . . . . . . . . . .
Combination of AES and RSA . . . . . . . .
Multi-step Verification General Flow chart [3]

.
.
.
.
.
.
.

.
.
.
.

.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.

.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.

2
6

.
.
.
.
.
.
.

24
25
25
26
26
27
31

3.1 Credential Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Files Management Use Cases . . . . . . . . . . . . . . . . . . . . . . .
3.3 Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Entrance to the application . . . . . . . . . . . . . . . . . . . . . . . .
3.5 OTP Interaction between root client and server . . . . . . . . . . . . . .
3.6 Main screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 Forms of Bottom Sheet used in the Main Screen . . . . . . . . . . . . .
3.8 Other screens in the application . . . . . . . . . . . . . . . . . . . . . .
3.9 LAN Server Access Point . . . . . . . . . . . . . . . . . . . . . . . . .

3.10General Context Relationship Diagram . . . . . . . . . . . . . . . . . .
3.11The Application Specific UI Components Structure . . . . . . . . . . .
3.12Behind-the-scene Structure . . . . . . . . . . . . . . . . . . . . . . . .
3.13Decrypting and encrypting packets with SConnectInputStream and SConnectOutputStream . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.14Web Application Use Case . . . . . . . . . . . . . . . . . . . . . . . .
3.15Web Application Main Screen . . . . . . . . . . . . . . . . . . . . . .
3.16Web Application User Screen . . . . . . . . . . . . . . . . . . . . . . .
3.17Device-based Encryption . . . . . . . . . . . . . . . . . . . . . . . . .
3.18Device-based Decryption . . . . . . . . . . . . . . . . . . . . . . . . .

34
35
36
38
39
40
43
44
46
47
48
50
52
53
54
55
58
59

4.1 File browser list and grid mode, otp display screen, loading lock screen . 64

4.2 Demo navigation menu, profile screen, LAN Transferring IP Screen,
Add new file and folder feature . . . . . . . . . . . . . . . . . . . . . . 65
4.3 Demo register screen, transferring task watching screen, bottom sheet
menu, log-in screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
iv


4.4 Web Application Main Screen Demo . . . . . . . . . . . . . . . . . . . 67
4.5 Web Application Dashboard User Profile Demo . . . . . . . . . . . . . 67
4.6 Web Application Dashboard Devices Demo . . . . . . . . . . . . . . . 68
C.1 Activity Lifecycle and Fragment Lifecycle [4] [5] . . . . . . . . . . . . 79
D.1 React Component Lifecycle [6]

. . . . . . . . . . . . . . . . . . . . . 80

v


ABSTRACT
Cloud Service has become an essential tool which tremendously supports business and individual to extend their storage usage. With regard
to overarching trends, the secure extent of such storage are most concerned for those that has confidential documents and resources stored
in these cloud server. Accordingly for Small and Medium Businesses
(SMBs), as a way to optimally use the maximum amount of storage
within a limited range of expenditure, one common storage will be used
in order to store multiple files across employees. The regard way of using cloud storage has posed a problem of securing hierarchically confidential files against some extent of jurisdiction. Some of cloud services
may implement ways to protect a particular files with password created
by the administrator of the storage. However, these may only be a temporary method to provide required security but not absolutely secure
it.
In this project, the authors attempt to provide a solution for providing security in a common shared cloud storage based on the idea of
device-based encryption. As regards encryption, files will be encrypted

using an identifier which can uniquely identify the only device that can
decrypt or access the confidential information within. Moreover, the
authors implemented an application to offer a service with regarding
encryption idea and advantageous flow to avoid losing data in such case
that users lost their unique device. Furthermore, two-factor authentication will be applied to authorize a new device to decrypt the encrypted
files for further modification and display. Beside that, the application
also centralizes the cloud drive services used by an user, files can be
accessed and managed across different cloud drives in just one application instead of installing multiple applications to utilize the services.

vi


After considering the given time for the project and requirements
from our own proposal, the authors decided to develop the applications on only two platforms: An android application for authentication,
encryption, authorization as the root device and a website for deauthorizing the root device in case it is lost or disabled permanently, and for
editing profile information. The client mobile application plays the role
of accessing files and providing a comfortable service for users to manage files. Encryption process is only performed within the root device
with the android platform running.
Keywords: unique identifier, device-based encryption, two-factor authentication, user-name and password authentication.

vii


CHAPTER 1. INTRODUCTION

Chapter 1

Introduction
As an important development of technology, Cloud Service plays an essential role for business and individual which provide an advantageous
solution for storing data in a greater extent without spending huge expenditure for hardware upgrading and maintenance. Replacing the simplest solution of purchasing extended hard drives for storing and backing up the data, which is not yet mentioned with other bills for maintaining these hard drives and data at a fully-protected condition, Cloud

Service is considered to be a reliable and affordable option for Small
and Medium Businesses (SMBs) as its storage can be paid monthly or
annually depends on the businesses’ factors. Additional services and
tools may be purchased along side with Cloud Service to build up a circulation or a work-flow restrained to the company’s policies and regulations. Smaller companies may consider purchasing an appropriate pack
of service for providing enough storage with smallest expenditure. Not
only reliable data backup solution is served, instant access from everywhere and simple file sharing or large file sender which email cannot
accommodate are key factors to create overarching theme for SMBs.
The proposed application that we built is implemented initially on only
two platforms as its purpose of providing extended method for data security. Therefore, two platforms are enough for the application to show
its capabilities of device-based security. The authors implemented the
client within Android OS platform which has the biggest share in the
mobile operating system market, where the demo application can have
wide test environment [7]. In order to process authentication, authorization and backup mechanism for essential data key, we built a mid-

1


1.1. OBJECTIVE AND SCOPE

CHAPTER 1. INTRODUCTION

Others:0.4
WindowsPhone:0.3
iOS:12.5
WindowsPhone:0.3

Others:0.4

iOS:12.5

Android:86.8
Android

iOS

Windows Phone
Others
Android:86.8
meta-chart.com

Figure 1.1: The mobile OS market shares in Quarter 3 of 2016 [1]

dle server Python programming language together with Flask framework (this concept will be explained more in the section Background) ,
which has flexibility and amplification [8].

1.1

Objective and Scope

The main problem lies in the sharing service of Cloud Services when
comprehensive security for confidential data is not available in an advantageous way. SMBs mostly purchase one storage only for multiple
extent of purposes. In regard to hierarchical storing purpose, it’s unable to protect data against invalid jurisdiction. Additional tools for
providing password to a particular folder or data may accommodate
temporarily these requirements but not entirely secure the data due to
human factors upon password-based protection as losing password or
being brute forced. Another matter is the pricing, cloud drive services

2

1.1. OBJECTIVE AND SCOPE

CHAPTER 1. INTRODUCTION

only provide a limited space to free users, to gain more spaces for storing files, users have to purchase, so an economical solution in using
cloud drive is using services of multiple providers. However, in that
case, users need to have the applications of those providers installed in
the users’ devices, which leads to the decrease of devices’ free spaces as
well as the inconvenience when managing files across the cloud drives.
From the observation above, the authors develop an idea of protecting data to avoid human factors which serve the regarding requirement
from SMBs that is to limit the access to the device level. On the other
hand, the authors also attempt to implement multiple cloud drive services into one client application with extendability to more services and
flexibility to changes or addition of functionality across services in the
future. In other words, the authors’ purpose is to build an application
which not only puts users’ files into safe mode but also ease the way of
managing files and lower the cost of consuming cloud drive spaces.
In order to secure data among shared cloud drive space hierarchically, we implemented an application for providing middle service to
encrypt confidential data locally before storing these data back to the
cloud. The application featured the security with different approaches
from regular authentication and encryption method to attempts to ease
the way of using. By applying state-of-the-art encryption method in
combination with advanced key system and several additional feature,
as well as utilizing the adaptability of third-party services (cloud drive
services), we built a service to raise a more secured and more efficient
solution for using cloud drives in order to meet common needs of SMB.
The application and proposed solution are based on some main concepts and requirements: device-based encryption, authorization mechanism, backup mechanism, extendability to more cloud services, files
management ability.

3

1.2. BRIEF DESCRIPTION

1.2

Brief description

1.2.1

Device-based Encryption

CHAPTER 1. INTRODUCTION

One of the most essential proposed solution for securing confidential
data among shared cloud drive is device-based encryption, which take
an identifier that can uniquely recognize the device. However, the used
identifier for encryption must be able to avoid spoofing, therefor, the
identifier must be generated privately or complex enough that cannot
be spoofed using modification within the hardware. There are currently
two well-used unique identifier which is generated globally by the manufacturers and associated with every single device separately: MAC
address and IMEI number. These two keys serve different purposes,
device identification for networking within the internet connection and
device detection for the Global Positioning System (GPS). Therefore,
the mentioned unique identifier is publicly known by the network or the
system, which make them vulnerable to spoofing. To remove such vulnerability, we attempted to combine unique identifier and non-unique
identifier to obtain a single unique and private identifier. Furthermore,
we designed a special flow of storing encryption key to enhance the
security extent which has device-based property and high level of security.
1.2.2

Authorization Mechanism

As device-based service, our application shrank down the accessibility of users to device level, which create inconvenient circumstances
for users to access their encrypted data. Although it can be considered
to be a trade-off when using this device-based security, we attempted
to provide user a more comfortable service. Hence, we implemented
a mechanism of authorization for accessing data from another device
rather than the root device without compromising security level and

4


1.2. BRIEF DESCRIPTION

CHAPTER 1. INTRODUCTION

fundamental principle of the application. The implemented mechanism
is mainly based on two-factor authentication in a similar fashion to popular authentication system, for instance, Google, Facebook and Steam
already provided such authentication mechanism. One-time password
(OTP) is a well-known technique used for two-factor authentication,
especially time-based one-time password (TOTP), which are explained
in the Background section. After processing authorization, another device is added to the device list associated with the user account and
is able to access data with device-based encryption. Our authorization
mechanism is built upon accumulative property, which can authorize
a finite number of devices and reserve device-based security, that is,
despite losing email and password or being spoofed with unique identifiers, encrypted data are still secured against invalid access.
1.2.3

Backup Mechanism

With a unique encryption key, there is a possibility of losing the key
due to some human errors, therefore, we implemented backup feature
in this project. In term of backup, we designed a mechanism for users
to generate and store a backup key associated with one unique device
in order to avoid losing data permanently when users lost their root devices. By providing storing this backup key, users maybe able to reauthorize another root device and restore encrypted data. Backup mechanism is mainly implemented to remove human factors but still secure
confidential data. The main key point to the backup mechanism is that
it must be implemented as simplest as possible to avoid performance
harming. Moreover, the mentioned mechanism need to be complex
enough to avoid vulnerable holes, which can be utilized to trespass the
security and steal confidential data. In order to achieve such property,
we proposed an idea of splitting the key into two partial keys and store
them in different places, for instance, one of the key will be sent to the
user’s email and the other one will be stored within the server. In case

5


1.2. BRIEF DESCRIPTION

CHAPTER 1. INTRODUCTION

of losing the device, the first key will be required for restoring the main
encryption key that is associated with the former device. Furthermore,
the splitted key is not directly used for encrypting data but encryption
key of the data. This approach of encryption will help to improve performance of encryption process due to frequent change of backup key
but persistent property of the main encryption key.
1.2.4

Extendability

Other
Acronis
SugarSync
CrashPlan
LiveDrive
Mozy
JustCloud
OpenDrive
Amazon S3
Carbonite
Box
iCloud
OneDrive
Google Drive
Dropbox
−5

0

5

10

15

20

25 30
%

35

40

45

50

55

60

Figure 1.2: Shares of cloud drive service for SMBs.[2]

Data from 289 small and medium businesses with 11-1,000 employees

It’s undeniable that there are enormous number of cloud drive services in the application market. Although at present, Google Drive

6


1.3. RELATED WORKS

CHAPTER 1. INTRODUCTION

and Dropbox are dominating the market for SMBs in the amount of
users [2], but other services such as pCloud, Box, OneDrive, Sync,
etc. are also potential to make the fight more balanced [9]. From that
reality, users’ combination of cloud drive services are large, then it requires the application to have ability that allows the authors to implement more services with ease to cover more widely users’ cloud drive
trends. Based on the common features of a cloud drive services, an

adapter with basic behaviors is built to connect all cloud services into
one hub . The uniqueness in behaviors of each cloud service is handled
in each end point. At present, the authors decided to choose Google
Drive and Dropbox as the beginning implemented cloud drive services
due to their popularity to SMBs which can be seen in Figure 1.2.
1.2.5

Files management

To manage files and folders, it is obviously easier for user when using
a file browser. This manner appears first in personal computer (PC)
application and it has been also applied to mobile application since the
first smart phone was introduced. Therefore, the authors built the client
mobile application with the appearance of a file browser initially with
basic functions to meet the users’ habit in working with files and folders
over years. This file browser will be used to explore the files and folders
in the users’ cloud drives as well as the application local drive.

1.3

Related Works

The idea of device-based authentication and authorization is not new
to the introduced technology. As stated by an article [10], devicebased authentication is used as an alternative layer of authentication
for authenticating the machine over the user information. Moreover,
the referenced article [10] brought up about the “Trusted Computing
Group (TGC)” that involved numerous large companies of technology,

7

1.3. RELATED WORKS

CHAPTER 1. INTRODUCTION

whose main goal is to build up such “standard specifications for computer hardware trusting” in order to improve data storage security. In
other words, the regarding standard’s purpose is for authenticate in machine level.
Not just an idea or any standard specifications that involved in devicebased authentication, there is already authentication system that is built
upon this principle to provide a more secure service for the user. For instance, the casino and sportbooks “5Dimes” [11] has already provided
such extent of authentication to their users. As proposed by “5Dimes”,
their device-based authentication is designed to authenticate a machines
based upon numerous factors [11]: “browser version”, “security cookies”, “language characteristics”, “operating system version”, etc. which
is far more complex than our proposal of device-based authentication
method.
For better understanding this paper, the authors list out main points
here. The thesis project is put in context of the field of data security.
The core content of this thesis is presented in five chapters: Introduction, Background, Methodology, Results and Conclusions.

8


CHAPTER 2. BACKGROUND

Chapter 2

Background
In the foregoing project, we separately built the service upon two main
applications: the client and the server applications which operate individually and communicate using a predefined standard. In term of
server, we dealt authentication, registration and authorization as it is unable to process these operations locally. With regard to data operations,
it’s the client side to perform locally due to the manner of device-based

security as it can only be decrypted using a unique keys generated from
devices’ identifiers.
In this chapter, we present general information about used technologies
and techniques in both of the client and the server applications, which
are demonstrated in three sections: Server-side Development, Clientside Development, Cryptography and Multi-step Authentication.

2.1

Server-side Development

2.1.1

Representational State Transfer

The main server was built upon Python-based Flask framework that
process most of general authentication, registration and authorization
request from the client. Our server was built as a Representational State
Transfer (REST) application, which can run as a stand-alone server.
This allow us to create a distributed application that can serve multiple
client framework using Hyper Text Transfer Protocol (HTTP) as the
underlying protocol of hypermedia communication. As an Application
Program Interface (API) oriented service, RESTful server is recently
included in frameworks of any major development language due to its

9


2.1. SERVER-SIDE DEVELOPMENT

CHAPTER 2. BACKGROUND

lightweight, maintainability and scalability [12, p.33]. An overarching themes of using RESTful to serve authentication and registration
purposes for cross-device applications has resulted in a substantial development of RESTful service upon major development languages and
technologies, for instance, Machine Learning, Deep Learning and Artificial Intelligence can now be integrated with a RESTful server.
RESTful service work upon several essential principles which make
it a powerful service for both website application and mobile application. The following four principles are considered as key principles of
RESTful service [13, p.407]:
• Addressibility: Each building block (resource) within a RESTful
service must be identified with an identity, which can be done by
using URIs as the identification. In such manner, resources can be
retrieve or manipulated easily with unique and global URI without
confusion toward data or operations. Any type of building block is
considered as a resource that merit identification: abstract resources
as a process, a step, a request, a response or typical resources as
data objects, rows of data, text fields, etc. As constituent resources
are retrieved and manipulated, it provides prosumers the reusability
of partial components or resources.
• Statelessness: Statelessness of RESTful service is addressed in the
manner of communication but not functionality. There is no state
of the communication between client and server reserved in either
storage. Instead, data or functional state can be reserved and stored
within client or server storage for process further operations toward
received or sent resources by a stateless communication. This principle has several direct impacts on the interacting resources, flexibility of the model and scalability of RESTful [13, p.407]. In term
of scalability, enormous number of interacting users may seriously
affect server’s footprint as it is needed to store client state within
the server. Moreover RESTful service “allows easy rearranging the

10

2.1. SERVER-SIDE DEVELOPMENT

CHAPTER 2. BACKGROUND

application at run time” [13, p.407] which enhance the flexibility
of the model.
• Connectedness: This principle address the link between resources
within RESTful service based on hypermedia, considered as “backbone of RESTful appplications” [13, p.408]. Enormous number of
books and thesis have mentioned about this principle as its first introduced name by Fielding [14]: “Hypermedia As The Engine Of
Application State” or abbreviated as HATEOAS principle. It claims
that the client may enter or terminate at any state of the workflows
with a proper URIs. [13, p.408]. It such manner, a workflow can
be more lightweight and dynamic as data retrieved only when it is
needed using a linked URI.
• Uniformity: This principle enables RESTful application to process
requests from multiple frameworks or operating systems, for instance, website applications and mobile applications, by following standardized method, name and semantics, for instance, POST,
GET, PUT and DELETE are very common standard of communication methods that serve different purposes. The used standard
does not address any of data encoding but operations name and semantics, which should be defined upon its means of operations and
resources [13, p.408].
2.1.2

Python and Flask Framework

Python is a high-level and interpreted programming language, which
has a low learning curves for both beginners and experienced developers. Python is only effective in building an application which does not
deal with direct communication between application and hardware [15]
or involving concurrency handling [16, p.3]. After the release of Python
2.0 in 2000, there has been an substantial growth in the number of applications built upon Python [17, p.5] and numerous versions of Python

11

2.1. SERVER-SIDE DEVELOPMENT

CHAPTER 2. BACKGROUND

has been released [18]. Moreover, Python has become an overarching fashion due to its enormous number of strong libraries that support
Artificial Intelligence, Computer Vision, Machine Learning and Deep
Learning [19], which recently has been being developed, researched
and applied by most of large industries and co-operations for processing big data, for instance, Google, Facebook and Apple are well-known
for applying these technologies in any major.
In addition to desktop application, Python has also been using for
building website application [20] and mobile applications [21]. In a
similar fashion to most of popular development language, Python has
a diverse library system which can be contributed by individuals or industries to provide a certain operation underlying many different extent
from a simple computation to the most complex algorithmic operation.
As being supported by a huge community of Python developers, its library system has been surging in the number of useful libraries. This
enables developers to easily use these libraries in combination with core
operations for creating more complex and practical applications. Moreover, Python is an object-oriented scripting language that provide the
capacity of defining classes of objects and inheritance trees for reusability [17, p.19]. Python allows developers to dynamically define, allocate
and call a declared variable without a proper static declaration upon its
data type by using a comprehensive set of data types. This flexibility
in data representation, declaration and usage has create a more comfortable manner for developers [17, p.6]. These strength of Python
have encourage many industries to build commercial website engine
and website application. One of the marketable engine being used by a
massive population of users is the Google Search engine which crawl
an immense number of websites and process through a huge set of data
to classify them associated with topics, key-words and even images. As
recorded, Google engine is not the only web service that was built upon

12


2.1. SERVER-SIDE DEVELOPMENT

CHAPTER 2. BACKGROUND

Python, there are many commercial and non-commercial websites and
applications have been built [17, p.18]. From regarding advantages,
we decided to use Flask, a Python framework to implement our server
for handling authorization, authentication, registration and data backup
operation.
Flask is a micro-framework that was built upon Python programming language that support development of web services. Flask can
be integrated with both relational database and NoSQL database [20,
p.xi] which provide a wide range of options for choosing an appropriate database system. Deriving one of the core advantages from Python
development language, Flask has enough solid core and a massive number of extended third libraries for building a maintainable and scalable
application [20, p.3]. There is only two main dependencies that Flask
was built upon [22]:
• Werkzeug [23] provides Flask with “the routing, debugging and
Web Server Gateway Interface (WSGI) subsystem” [20]
• Jinja2 [24] is the main “template engine”[22] for Flask to create
basic layout of the website. By using template engine, Flask developers have saved times for building applications involving frequent
updating and maintenance.
Basically, a Flask running server have an object to handle all of requests
from server which is referred as an application instance [20]. In order
to handle requests, the application instance must follow the WSGI protocol mentioned earlier as one of the main dependencies of Flask. In
the application, routes of resources are defined for handling specific
requests associate with an URL. This follows the Addressibility principle of Representational State Transfer service introduced above.
From a valid request with preconditions passed, the server handles the
request by calling the function that is associated with the request URL

13


2.2. CLIENT-SIDE DEVELOPMENT

CHAPTER 2. BACKGROUND

and return a proper response object. As defined in the standard used
by Representational State Transfer service, a response object is an
HTML object or a JSON type object which contains response data or
messages and HTTP status code [20, p.15]. The status code of a response defined in the Request For Comments [25, p.296] as a set of
families of code which includes: “Informational”, “Successful”, “Redirection”, “Client Error” and “Server Error” associated with each first
digit of the code from 1 to 5 respectively [26, p.505]. When receive a
response, the client begin to assess the status of the response by these
status codes, there should be an appropriate action defined by client
taken upon each of these codes. Using a predefined standard of codes
create a consistent handling method between server and client, which
reduce time consumed for response and request interpreting.

2.2

Client-side Development

2.2.1

Android and the basic knowledge

Android is a mobile operating system founded by Andy Rubin, Rich
Miner, Nick Sears and Chris White in 2003 before being acquired by

Google in 2005 [27]. Applications running on Android platform are developed with Android software development kit (SDK) [28, p.7] which
is powered by Java Programming Language [29], and allows the combination with optional C/C++ support framework [28, p.445], but at
current stage, the authors’ project have not needed C/C++ support in
android development.
Application core components

Android’s application framework lets developers comfortably and innovatively create apps using a set of reusable components. This part
give readers a quick and very fundamental look on the how an android
application works based on the Android SDK.

14


2.2. CLIENT-SIDE DEVELOPMENT

CHAPTER 2. BACKGROUND

• Activity: an instance of Activity class can be considered as the entry point of an application to handle interactions with users, managing a window in which User Interface (UI) is drawn. This window
may fill up the screen, or apart of the screen and be floating over of
other windows. To implement developers own logic that manages a
window or a screen, they create a subclass extending Activity class,
so an Activity is not only a unit to represent user interface interaction but also a unit to carry out some under-the-hood calculation.
[28, p.77]
An application usually contains many screens, that means the number of activities is larger than one, and for each application, there is
always one main activity which plays as the very first screen interacting with users, called the launcher. Each activity can also open
another activity for different purposes from the current one via Intent. [28, p.78]
Further than ability to start another activity defined in the same
application, an activity can also start the activity of another application by Intent with appropriate input.
An activity has a life cycle which define specific events that take
place during its living time [28, p.90]. It can be found at Appendix

C of this paper.
• Service: a Service object is used to perform long-term actions in
background of Android Platform without user interface, even after the holding application is out of scope (users switch to another
application or to home screen but they have not killed the application). A service can be started from another context such as an
activity or another service. [28, p.79]
• Intent: an Intent instance is used as a messaging object to request
an action from an application component to another ones. There are
three fundamental cases of using intents: first is to start an activity,

15


2.2. CLIENT-SIDE DEVELOPMENT

CHAPTER 2. BACKGROUND

second is to start a service, and third is to send broadcast messages,
which can be understood as global announcements which any running application can receive.[30]
• Fragment: a Fragment instance behave as a portion of UI in an activity, multiple fragments can combine together to build a complete
multi-panel UI of a screen. The advantages of a fragment is the
reusability and the simplicity when dealing with smaller separate
UI components instead of the whole bundle of components put in
just one activity class. A fragment instance also has a life cycle
affected directly from the parent activity [28, p.197], the life cycle
can be read for more details in Appendix C.
• Content Providers: this is a standard interface of Android operating system that provide a secured and official manner to access an
application data as well as other applications data stored in the Android device. It works as an RESTful web service that has the basic
manipulation such as insert, update, query, delete [28, p.79]
• AsyncTask: this component allows developers to perform works on
a different thread from UI thread and return the results to UI thread.

The result can be an update of a progress or the final output of the
whole work.[28, p.143-154]
Application User Interface

In android, building user interface includes main concepts: layout,
menus, custom components, styles and themes. However, basically,
layout is the most fundamental concept because it defines the visual
structure for a UI components like activities, fragments, or app widgets. Layouts can be declared in two ways:
• Pre-declaring UI elements in XML files: Android uses XML format to define user interface, so it also provides some overhead

16


2.2. CLIENT-SIDE DEVELOPMENT

CHAPTER 2. BACKGROUND

vocabulary corresponding to built-in View classes and subclasses
which can be utilized and combined to speed up the UI building
process. The advantages of this approach are the reusability to combine with another layout xml declarations to build a more complex
UI element, the separation from the logical part handling events
and changes in UI interface, the coherent visualization of the Android Visual Editor help developers recognize the defects and bugs
more effectively. One more thing, menus are also usually declared
in an XML file before hand.
• Initiate UI elements at run-time: As stated above, each XML
tag or element in android development correspond to a native View
class or subclass. Therefore, a View object or instance can be created programmatically and then attached to a presented parent view.
This manner allows views to be dynamically initiated and added to
the user interface at run-time, the UI is flexible to changes, but it is
somehow challenge the developers because there is no preview for

them to thoroughly observe the behaviours of the UI.
2.2.2

Client Cloud Drive APIs

A Cloud Drive is a service that bases on web technology to provide storage space on a remove server, as well as a tool set to manage data stored
in that storage [31]. API, which was aforementioned without clear explanation, is a contract established between the component providing
the supportive functionality and the component utilize that functionality (client) [32, p.1]. Therefore, Client Cloud Drive APIs are the sets of
supportive adapting tools to receive the requests for data in Cloud Drive
from the client, process the request, send request to the cloud drive remote server, get back the responses, process the responses and return
appropriate data to the client. The main speciality of this kind of API
is the integration at client application to ease the sending request and
receiving response tasks to the API in the remote server whereas the

17


2.2. CLIENT-SIDE DEVELOPMENT

CHAPTER 2. BACKGROUND

API of this project is a server API that control some of security tasks of
the client application.
As stated in the Introduction, Google Drive and Dropbox are two
drives selected to be the initial drive services integrated with this project
application, therefore, their client APIs are implemented at the client
application to managing data on the remote more efficiently. Because
two drive APIs have different providers, the behaviours of each one is
definitely different in some way, but they still follow some standards of
a cloud drive. Understanding that matter, the authors attempt to build

an extremely neccessary adapter to connect different client drive APIs
into a common API.
2.2.3

Local Area Network (LAN) Server

A local area network or LAN is a computer networks which allow
computers to each other in an specific limited area like a neighborhood, a school, a lab, an university campus or an building[33, p.5]. A
server on the other hand is a computer that provides dedicated services
such as file service, web service, remote access, database, monitoring,
thread management, email service [34, p.2-3]. From those definitions,
LAN Server can be understood as a computer play the role of a service
provider on a limited area computer networks, which in the context of
this project, is the android device installed the output application of the
project.
For instance, Alfresco JLAN is an application which can be considered as an embedded virtual file system that is able to be integrated
to Java client and server with built-in CIFS (Common Internet File
System). JLAN with CIFS can be applied to LAN to work as an
LAN Server to manage shared data as well as user-specific data by
using NTLM (NT LAN Manager, which is used by Windows NT)

18