# F2AC: A Lightweight, Fine-Grained, and Flexible Access Control Scheme for File Storage in Mobile Cloud Computing

Authors: Wei Ren; Lingling Zeng; Ran Liu; Chi Cheng
Journal: Mobile Information Systems
 (2016)

---

## Abstract

Current file storage service models for cloud servers assume that users either belong to single layer with different privileges or cannot authorize privileges iteratively. Thus, the access control is not fine-grained and flexible. Besides, most access control methods at cloud servers mainly rely on computationally intensive cryptographic algorithms and, especially, may not be able to support highly dynamic ad hoc groups with addition and removal of group members. In this paper, we propose a scheme called F2AC, which is a lightweight, fine-grained, and flexible access control scheme for file storage in mobile cloud computing. F2AC can not only achieve iterative authorization, authentication with tailored policies, and access control for dynamically changing accessing groups, but also provide access privilege transition and revocation. A new access control model called directed tree with linked leaf model is proposed for further implementations in data structures and algorithms. The extensive analysis is given for justifying the soundness and completeness of F2AC.


---

## Body

## 1. Introduction

With the pervasive usage of mobile handheld computing devices such as mobile phones, tablets, and laptops, mobile business processing becomes possible and grows largely during commercial traveling. As storage services in cloud, such as Google, Alibaba, and Baidu, are freely provided, users may rely on these services to share and edit business files with others remotely and cooperatively. For example, after one user creates or uploads a file into cloud servers, the others can access the file remotely and edit the file cooperatively.Currently, mobile storage cloud services impose a typical security problem, access control for distributed users who will access the shared file in cloud servers. In particular, the related access control policies should be determined by user themselves, which result in sophisticated requirements. Moreover, many service providers simply assume that the other users have almost the same access privileges as the original user who creates and uploads files. It can simplify management logics at cloud but raise the risks of file leakage at client. That is, the other users can arbitrarily read, modify, and update uploaded files, which usually imposes security risks in mobile scenarios.For example, a user (calledA) uploads a file into a storage cloud. She tells the other two users (called B and C) user name and password for logging into the storage cloud. B and C can use the user name and password to successfully log into the storage cloud and access the file, like A. In other words, A, B, and C have the same privilege for the file, which is not fine-grained. It may result in security risks such as the leakage or damage of files.When the number of uploaded files and shared users increases, the fine-grained access control of those files for those users is mandatory. It is worth to note that because access control policies are not determined by the administrator of cloud servers, control methods should be so easy that ordinary cloud users can understand and conduct straightforwardly. It should be flexible in that access control policies are user-centric and can be defined on demand via operational interfaces provided by cloud servers. Moreover, the access control should be lightweight; otherwise, the response delay upon accessing will not be endured and user experiences will be worse to damage the QoS (Quality of Service) of storage cloud services.Recently, access control in storage cloud has attracted more and more attention [1–3]. However, in those methods a fine-grained, flexible, and lightweight solution has not been thoroughly explored. We make the first attempt to solve it in this regard. However, such an access control scheme poses three challenges as follows:(1) The flexible property requires that the proposed method must tackle complicated situations such as highly dynamic ad hoc groups, in which accessing users can join and leave groups conveniently. Moreover, all users may not be in the same layer (in terms of file sharing relationships). That is, a leader of a group can be authorized by the initiator and the leader can further assign and revoke privileges to other group members. A subgroup (or sublayer) can be formed in a group or a layer, so the authorization can be conducted in an iterative manner.(2) The fine-grained property requires that user privileges should be easily defined, changed, revoked, verified, and managed via various rules and policies. And especially, those can be determined and controlled by cloud user themselves. The access control mechanism should smoothly make it possible for users to edit shared files remotely, cooperatively, and securely.(3) The lightweight property requires that computational overhead should be managed in cloud side, as the total number of users in storage cloud is always huge. Thus, cryptographic algorithms should be avoided as least as possible. The computational overhead at mobile clients should be as least as possible for better performance in energy consumption and user experiences.In this paper, we propose a scheme called F2AC (lightweight, fine-grained, and flexible access control) to tackle the above challenges. We present and analyze the design rationale in an incremental way for better understanding. Some formal presentations are presented for better clarity and rigorous generality.The contributions of the paper are listed as follows.(1) F2AC can create, add, and delete users in a group (and a subgroup iteratively), authorize a user as a group leader who can authorize privileges to other group users iteratively, and revoke privileges for a user in the group.(2) F2AC can manage access control such as merge, delete, and retrieve user or privileges in a lightweight manner via a proposed access control model, directed tree with linked leaf model.(3) F2AC can permit users to define various access control rules as they demand and separate the access control for system users and file users, which simplifies user experiences and management flows in cloud.The rest of the paper is organized as follows. Section2 gives an overview on relevant prior work. In Section 3 we discuss the basic assumption used throughout the paper. Section 4 provides the detailed description of our proposed models and analysis. Finally, Section 5 concludes the paper.


## 2. Related Work

Access control methods for mobile cloud have attracted more and more attention [1, 3, 4]. Ghafoor et al. [5] suggested to enable users to create and manage access control policies on their resources according to their own security and access control requirements. They proposed a framework, standard policy definition language, and user interface to specify and manage access control. Tang et al. [6] designed and implemented a secure overlay cloud storage system that achieves fine-grained, policy-based access control and file assured deletion. Habiba et al. [7] presented framework and different modules along with their functionalities. They also described Multiagent Based System (MAS) and an enhanced authorization scheme. Ruj et al. [4] proposed a new decentralized access control scheme that supports anonymous authentication. Their scheme prevents replay attacks and supports creation, modification, and reading data stored in the cloud. Wan et al. [8] argued that attribute-based encryption (ABE) suffers from inflexibility in implementing complex access control policies. They thus proposed hierarchical attribute-set-based encryption (HASBE) by extending ciphertext-policy attribute-set-based encryption (ASBE) with a hierarchical structure of users. Hajivali et al. [9] proposed agent-based user authentication and access control algorithm based on discretionary and role-based access control model for increasing the reliability and rate of trust in cloud computing environments. Their model uses a cloud-based software-as-a-service application and a client-based user authentication application. Ortiz et al. [10] discussed the industrial application of the extensions to traditional role-based access control to enable secure and mobile collaboration among manufacturing enterprisers. Lv et al. [11] proposed a modified CP-ABE algorithm to set up a fine-grained access control method, in which user revocation is achieved based on the theory of Shamir’s secret sharing. Yang et al. [12] proposed to delegate the computation intensive task, such as data reencryption, key distribution, and derivation to cloud servers. Their scheme required bilinear pairing and random padding. Yao et al. [2] proposed a lightweight cipher-text access control mechanism based on authorization certificates and secret sharing for mobile cloud computing. Jung et al. [3] proposed to control privilege and anonymity by fully anonymous ABE. Shen et al. [13] studied the problem of keyword search with access control over encrypted data in cloud. They proposed a framework where user can use his attribute values and a search query to locally derive a search capability, and a file can be retrieved only when its keywords match the query and the user’s attribute values can pass the policy check. They also proposed a scheme that utilizes HPE to enforce fine-grained access control, and support the derivation of the search capability. We argue that most of current works extensively rely on ABE, which may not be lightweight due to encryption operations. Moreover, ABE-based schemes cannot support flexible self-defined access policies or cannot be fine-grained in terms of dynamical and iterative privilege authorization (and revocation) when ad hoc groups change and group members vary.


## 3. Problem Formulation

### 3.1. Network Model

There exist at least three major entities in file storage cloud: an entityA who uploads files and shares those files, an entity B who is asked to access these files, and a storage server C who is at cloud side. Simply speaking, A uploads files into C. A gives login account information to B. B logs in and accesses files according to her privilege that is set by A.In this paper, we will tackle more complicated scenarios and manage access privileges in a fine-grained, flexible, and lightweight manner.Definition 1 (original user).
This is the user who applies for an account from a cloud storage service for uploading files, for example, Alibaba’s AliYun. She uploads files into the cloud server. She is denoted byUserA in further examples.Definition 2 (accessing user).
After original user logs in to cloud and uploads files, she will be asked to assign access privileges to some accessing users for those files. Original user also needs to specify accessing user’s account information for logging in to cloud systems and token information for distinguishing different users for file accessing.Definition 3 (team leader).
In accessing users, some are team leaders who can assign privileges for shared files in this team. Team leader can also add and remove accessing users in this team.Definition 4 (team member).
Accessing user who is added by a team leader or original user is a team member in this team.Definition 5 (privilege).
An accessing user accesses an uploading file according to her privilege that is authorized by team leader or original user.Definition 6 (authorize privilege).
Original user and team leader can have authorize privilege, who can assign privileges to other users, and add or remove accessing users.


### 3.2. Design Goals

The design of F2AC should tackle the following situations: (1) Original user and team leader can authorize privileges for a highly dynamic group in which users can be added or removed. (2) Those privileges can be flexibly managed by original user or team leader in an iterative way and accessing hierarchical layers can be diverse and arbitrary. (3) The access control can be conducted in a lightweight manner at cloud, especially when system access control is separated from file access control, which is a realistic deployment requirement in storage cloud.


## 3.1. Network Model

There exist at least three major entities in file storage cloud: an entityA who uploads files and shares those files, an entity B who is asked to access these files, and a storage server C who is at cloud side. Simply speaking, A uploads files into C. A gives login account information to B. B logs in and accesses files according to her privilege that is set by A.In this paper, we will tackle more complicated scenarios and manage access privileges in a fine-grained, flexible, and lightweight manner.Definition 1 (original user).
This is the user who applies for an account from a cloud storage service for uploading files, for example, Alibaba’s AliYun. She uploads files into the cloud server. She is denoted byUserA in further examples.Definition 2 (accessing user).
After original user logs in to cloud and uploads files, she will be asked to assign access privileges to some accessing users for those files. Original user also needs to specify accessing user’s account information for logging in to cloud systems and token information for distinguishing different users for file accessing.Definition 3 (team leader).
In accessing users, some are team leaders who can assign privileges for shared files in this team. Team leader can also add and remove accessing users in this team.Definition 4 (team member).
Accessing user who is added by a team leader or original user is a team member in this team.Definition 5 (privilege).
An accessing user accesses an uploading file according to her privilege that is authorized by team leader or original user.Definition 6 (authorize privilege).
Original user and team leader can have authorize privilege, who can assign privileges to other users, and add or remove accessing users.


## 3.2. Design Goals

The design of F2AC should tackle the following situations: (1) Original user and team leader can authorize privileges for a highly dynamic group in which users can be added or removed. (2) Those privileges can be flexibly managed by original user or team leader in an iterative way and accessing hierarchical layers can be diverse and arbitrary. (3) The access control can be conducted in a lightweight manner at cloud, especially when system access control is separated from file access control, which is a realistic deployment requirement in storage cloud.


## 4. Proposed Scheme: F2AC

### 4.1. Basic Setting

There exist two tables for facilitating control mechanism atCloud. We denote them as Cloud⩴ACL,UCL, where ⩴ can be looked as “is defined to.” ACL is used for access control; UCL is used for user authentication.(1)ACL is a table for access control that has four fields File∗,User∗,P,C, where File∗ denotes a file name, User∗ denotes a user name, P denotes a privilege, and C denotes one or more conditions. We denote it as ACL⩴File∗,User∗,P,C.The privileges usually have four types,Create, Update, Modify, and Read, which denote create, update, modify, and read, respectively. Users who are assigned Read privilege can only view files. Users who are assigned Modify can read and modify files but not update files. Users who are assigned Update can read, modify, and update the modified content into files. Users who are assigned Create can read, modify, and update files and, especially, can assign privileges to other users. We denote it as P⩴Create,Update,Modify,Read. The former one is the superset of the latter one. That is, Create contains the privilege Update, Update contains Modify, and Modify contains Read. In shorthand, Read⊂Modify⊂Update⊂Create.Extra conditions (columnC) can include more requirements for access, for example, locations, device MAC addresses, or any other requirements. The default value for it is Null, denoted as ∗. We denote it as C⩴∗,Loc,MAC.(2)UCL is a table for user control that has two fields User∗,Token∗, where User∗ is a username and Token∗ is a password for user authentication. We denoted it as UCL⩴User∗,Token∗.F2AC is composed of the following steps.Step  1 (user: firstly login and upload). For the first time login, UserA can upload one or more than one files into CloudC.Step  2 (user: assign one user and one privilege for one file). Once UserA uploads a file successfully (e.g., FileA1); Cloud will add two records into ACL as follows.Step  2.1. One record is FileA1,UserA,Create,∗ that is added into ACL automatically.Step  2.2. UserA will be asked to set up the access privilege of the file (FileA1) by Cloud. That is, UserA specifies the privilege (e.g., Read) of FileA1 to UserB by checking the options (in user interface) provided by Cloud. The setting results will be stored in ACL. That is, the record FileA1,UserB,Read,∗ is added into ACL.Step  3 (user: assign more users and their privileges for one file).
User
A continues to set up more users and more privileges for this file. Cloud add more records in ACL correspondingly. That is, Step 2.2 will be conducted iteratively for FileA1 for assigning more users and privileges.Step  4 (user: upload more files and assign more users and their privileges for more files). If UserA uploads additional files, for example, FileA2, FileA3, Steps 2 and 3 will be reconducted iteratively for those files by Cloud and UserA.Step  5 (cloud: store records into
A
C
L
). After UserA uploads all files and sets up all options for access control, Cloud will store corresponding records into ACL.Step  6 (user: assign
UCL
).
User
A sets up corresponding token for each user in ACL including herself by checking options (in user interface) provided by Cloud.Step  7 (cloud: store records into
UCL
). After that, Cloud stores corresponding records into UCL. For example, UserA,TokenA,UserB,TokenB,UserC,TokenC.Step  8 (user: send account information and tokens to accessing users).
User
A gives her account and password for Cloud, together with TokenB, to UserB; UserA gives her account and password for Cloud, together with TokenC, to UserC. The account and password of UserB and UserC are the same as those of UserA. The token is used for authentication and distinction of different accessing users.Step  9 (user: secondly login and present token). After UserA logs in to Cloud at the second time, she will be asked for her token by Cloud. The reason is that UserA is in UCL at this time.Step  10 (cloud: retrieve
UCL
and
ACL
). After UserA responds her token, Cloud will retrieve UCL to get the user name, namely UserA. Cloud lists all files for UserA by retrieving ACL according to her privileges.Step  11 (other users: login and present token). After UserB logs in to Cloud, she will be asked for showing her token by Cloud. After UserB responds with her token, Cloud will conduct processes similar to Step 10.Remarks 1.
(1) It is required to separate the authentication for logging in toCloud and the authentication for access control, namely, user name in UCL. It will simplify the implementation and management of user authentication at Cloud. The security of original authentication system of Cloud will not be damaged. It is also easy for UserA to understand (for better user experience) and conduct user addition for file accessing.
(2) In Step2.2, one privilege is already enough, as relationships between privileges are subset (or superset). The highest (or largest) privilege is set for one user aiming at one file.
(3) The conditionC could be extra accessing rules on demand, which is set “∗” in the description for simplicity. Indeed, it can be set as Loc, MAC, and so on. Hereby, C⩴∗,Loc,MAC. C can be considered as the extension of P.
(4) Step8 is usually accomplished offline or out of the channel, which is out of the scope of the scheme.


### 4.2. Notations

The major notations used in the remainder of the paper are listed as follows for better understanding.Cloud: File Storage CloudP: Privilege, P⩴Create,Update,Modify,ReadLogin(Cloud,User∗): User Login Function. Login into Cloud as User∗Upload(File∗): User Upload File Function. Upload file File∗SaveACL(File∗,User∗,P,∗): Cloud Save ACL FunctionSetupACL(File∗,User∗,P,∗): User Setup ACL FunctionSetupUCL(User∗,Token∗): User Setup UCL FunctionSaveUCL(User∗,Token∗): Cloud Save UCL FunctionRequestToken(): Function Request Token by Cloud after User Login Returning Token∗RetrieveUCL(Token∗): UCL Retrieve Function by Cloud, Taking as input Token∗, Returning User∗RetrieveACL(User∗): ACL Retrieve Function by Cloud, Taking as input User∗, Returning File∗,P,C.


### 4.3. Abstract Model

The overall procedures are stated as follows in a shorthand for simplicity and clarity as follows.Abstract Model for F2ACStep  1
User
A
:
Login
(
Cloud
,
User
A
), UserA:Upload(FileA1);Step  2.1
Cloud
:
SaveACL
(
F
i
l
e
A
1
,
U
s
e
r
A
,
C
r
e
a
t
e
,
∗
);Step  2.2
User
A
:
SetupACL
(
F
i
l
e
A
1
,
U
s
e
r
B
,
R
e
a
d
,
∗
),
Cloud
:
SaveACL
(
F
i
l
e
A
1
,
U
s
e
r
B
,
R
e
a
d
,
∗
);Step  3
User
A
:
SetupACL
(
F
i
l
e
A
1
,
U
s
e
r
C
,
M
o
d
i
f
y
,
∗
),
Cloud
:
SaveACL
(
F
i
l
e
A
1
,
U
s
e
r
C
,
M
o
d
i
f
y
,
∗
);
User
A
:
SetupACL
(
F
i
l
e
A
1
,
U
s
e
r
D
,
U
p
d
a
t
e
,
∗
),
Cloud
:
SaveACL
(
F
i
l
e
A
1
,
U
s
e
r
D
,
U
p
d
a
t
e
,
∗
);…Step  4
User
A
:
Upload
(
File
A
2
);
User
A
:
Upload
(
File
A
3
)
;
…Step  5
Redo  Steps  2.1, 2.2, and 3;Step  6
User
A
:
SetupUCL
(
User
B
,
Token
B
)
;
User
A
:
SetupUCL
(
User
C
,
Token
C
)
;Step  7
Cloud
:
SaveUCL
(
U
s
e
r
A
,
T
o
k
e
n
A
);
Cloud
:
SaveUCL
(
U
s
e
r
B
,
T
o
k
e
n
B
);
Cloud
:
SaveUCL
(
U
s
e
r
C
,
T
o
k
e
n
C
);Step  8
Off-line Operations.Step  9
User
A
:
Login
(
Cloud
,
User
A
);Step  10
Cloud
:
Token
A
⇐
RequestToken
(
);
Cloud
:
U
⇐
RetrieveUCL
(
Token
A
);
Cloud
:
File
∗
,
P
,
C
⇐
RetrieveACL
(
U
);Step  11
User
B
:
Login
(
Cloud
,
User
A
);Step  12
Cloud
:
Token
B
⇐
AskToken
(
);
Cloud
:
User
B
⇐
RetrieveUCL
(
Token
B
);
Cloud
:
File
∗
,
P
,
C
⇐
RetrieveACL
(
User
B
);
…Remarks 2.
(1) In Step1, UserA logs in for file uploading. After this login, UCL is created. In UserA’s next login (e.g., in Step 9), UserA will be requested for her token. If this time no file is uploaded, UCL will not be created. That is, once a file is uploaded by a user, UCL and ACL will be created at Cloud.
(2) In Step11, if a user (e.g., UserX) logs in via not using UserA’s account (including user name and password), Cloud will respond that this user (namely, UserX) is not a file sharing user related to UserA. It is an independent login, not being related to the file sharing of UserA (i.e., this login may be used for UserX’s file uploading and sharing).
In contrast, ifUserA logs in with UserB’s account, instead of UserA’s, UserA will be regarded as UserB’s file sharer and be requested for showing the token that is set by UserB.
(3) Usually,Create can be only assigned to the user who uploads the file into Cloud, by Cloud automatically in Step 2.1. In the following sections we will extend it for more flexible functions in more complicated application scenarios.


### 4.4. Extension for Flexibility

In the above abstract model, the major steps for F2AC are described. In this setting, only user that uploads the file can obtainCreate privilege and can authorize privileges to others. It can simplify the management of privileges, but it may not be convenient when the file is shared in a dynamic group whose members are changed frequently, or a group with a large number of users or different layers.For example,UserA uploads FileA, but UserA is willing to let UserB be a proxy of her for managing the file editing. Thus, UserA hopes that UserB can authorize privileges to other users as a team leader and represent as a proxy of UserA; for example, UserB can further assign privilege such as Read to UserC. To extend this flexibility, we propose an extension of basic settings and abstract model.Firstly,P⩴Create,Update,Modify,Read in basic settings will be extended to P⩴Create,Authorize,Update,Modify,Read. That is, the user with Authorize privilege will be able to authorize privileges to other users like UserA. Certainly, Authorize is a superset of Update, Modify, and Read.Secondly, in abstract model after Step12, if P that is returned by RetrieveACL(UserB) is Authorize, UserB will be able to set up ACL. Four policies are proposed hereby on methods for setting up ACL in the following.Policy 1 (none-transitiveAuthorize privilege and none-additive users).
AfterUserB with the privilege Authorize logs in into Cloud as UserA, all files are listed. UserB selects a file, for example, FileA1, and the related users and their privileges are listed. UserB can change those privileges that are Update, Modify, and Read. That is, only the user with Create can assign Authorize privilege; the user with Authorize cannot assign Authorize privilege to others but can change privileges such as Update, Modify, and Read. After any chance happens, ACL will be updated for column P for corresponding records.Policy 2 (none-transitive ofAuthorize privilege and additive users).
The difference between this policy and Policy1 is that the user with Authorize privilege can add more users for current files. If so, ACL will not only be updated at column P, but also be appended more records.
If the trace back on who adds the user into the group is required,ACL will be extended to File∗,User∗,P,C,ByWhom. ByWhom will record the user who adds User∗. For example, if UserA adds UserB into ACL, ByWhom will be UserA. If UserB with privilege Authorize adds UserC into ACL, ByWhom in this row will be set as UserB.
If a new user is appended intoACL, this user must be appended into UCL. The token of the new user is set up by the user who adds the new user. For example, if UserB with privilege Authorize adds UserC into ACL, UserB should set up UserC,TokenC in UCL.
The deletion of users inACL is only permitted by the user who matches ByWhom in this row. That is, if ByWhom is UserA in this row in ACL, only UserA can delete this row (namely, the user) from ACL (by user interface provided by Cloud). Once a user is deleted in ACL, the user will be also deleted in UCL automatically. For example, if ProjectColumn(ACL,User∗)!=UserB (i.e., all records like File∗,UserB,∗,∗,ByWhom=UserA are deleted in ACL by UserA), UserB,TokenB will be deleted from UCL.Policy 3 (transitive ofAuthorize privilege and nonadditive users).
The difference between this policy and Policy1 is that the user with Authorize privilege can change privileges Update,Modify, and Read into Authorize in ACL. That is, not only the user with Create can assign Authorize privilege, but also the user with Authorize can assign Authorize privilege to others. If so, the column P in ACL will not only be updated among Update,Modify, and Read, but also be updated from Update, Modify, and Read into Authorize. However, the user with Authorize privilege cannot add more users for current files, namely, nonadditive users.Policy 4 (transitive ofAuthorize privilege and additive users).
This one will be most complicated and flexible. It combines functions in Policies2 and 3. That is, the user with Authorize can assign Authorize privilege to others, and the user with Authorize privilege can also add more users for current shared files.Remarks 3.
(1) Each user has only one possibleByWhom in ACL. Once a user is added into ACL, the ByWhom field will be set. For better understanding, if we consider ByWhom as a parent (namely, father) and consider each user as a node, user graph will be considered as a directed tree. The direction is from a child or all children to the father. Recall that, for user deletion, only the father can delete directed child or children in the tree (if user B’s ByWhom in ACL is user A who currently logs in to Cloud, user A will be presented an option on whether deleting B or not in user interface).
Note that, for consistence, if a none-leaf node is deleted, the node’s all children will replace their fathers by the node’s father. (All children’sByWhom will be replaced by the node’s ByWhom.)
(2) A user’s privilege for a file can be modified by anyone who hasCreate or Authorize privilege for this file. For better understanding, we can look users with Creat and Authorize for a file as team leaders for this file. Other users with privileges such as Update, Modify, or Read for this file will be considered as group members for this file.
(3) Once a user is added intoACL, she will be added into UCL. The same user name presents only once in UCL. For better understanding, all users in UCL can be considered as a group whose members share the same login account information (namely, login user name and password) in Cloud as the original user who uploads shared files.
(4) For each file, only one user can haveCreate privilege. The user who has Create privilege is the original user (the one who uploads the file into Cloud). All users in UCL will share the same account information with this user who has Create privilege.
(5) A user’s father (according toByWhom field) has responsibility to deliver the account information and token to the user, usually offline.


### 4.5. Directed Tree with Linked Leaf Model

Policy4 is the most flexible (or powerful) one in all policies for file sharing in a dynamic group or a group with a large number of members. Intuitively, someone may suspect that this policy may result in some inconsistency due to the complexity of user addition, deletion, and transitive authorization. To make it clear, we propose a concept and implementation model for F2AC, which presents as a directed tree with linked leaf (leaves).(1) Users are organized in a tree structure. Each user presents as one node at the tree. The root of the tree is the user who uploads all current sharing files, namely, one who hasCreate privilege for those files. All users in the tree share the same login account information as the root, but they are distinguished via their tokens.(2) Each nonroot node has one parent (namely, father). Anyone of these nodes has a directed edge pointed to its father. The father is the user who adds a child node or children nodes in the tree. Only users who haveAuthenticate or Create privilege can add a child or children. The father of a child can be fetched from ACL by looking up ByWhom column.(3) Each node has three properties, namely,UserName,Token,OneParent. UserName and Token are assigned by node’s father. The property OneParent points to node’s father.(4) Each node links to one or multiple properties, calledNodeLink. Each link has two related properties. One is AccessFileSet; the other is OnePrivilege. AccessFileSet property is a set consisting of one or more files; OnePrivilege property is one privilege for files in AccessFileSet. Each node may have more than one AccessFileSet, but each AccessFileSet has one corresponding OnePrivilege (namely, the largest privilege). That is, each node links to one or more sets that represent access files, and each set has one bit to represent the privilege for this set. We look on one or multiple properties as linked leaf (leaves) for this node. The model is thus called a tree with linked leaf (leaves). Note that linked leaf is not a leaf node; leaf node is a node that has no child, but linked leaf is a property for every node.(5) The file set (usually consisting of multiple files) at the father node should be the superset of that (namely, file set) at a child node or children. It is nontrivial to be aware of but can be understood for the reason that father’s files are reassigned to a child or children to edit. Thus, a merging set of a child’s or children’sAccessFileSet is upper-bounded by the father’s AccessFileSet.(6)ACL and UCL can be constructed by the above tree model. The retrieval of ACL and UCL can be accomplished by underlying tree data structures and algorithms.We denote the tree model in the following.Directed Tree with Linked Leaf Model
Tree
⩴
Root
,
NodeSet
,
Edges,
FileSet
⩴
files
∣
uploadedbyRoot,
Root
⩴
UserName
,
Token
,
OneParent
=
NULL
,
RootLink,
RootLink
⩴
AccessFileSet
=
FileSet
,
OnePrivilege
=
Create,
NodeSet
⩴
N
o
d
e
,
…
,
N
o
d
e
Node
⩴
U
s
e
r
N
a
m
e
,
T
o
k
e
n
,
O
n
e
P
a
r
e
n
t
,
N
o
d
e
L
i
n
k,
NodeLink
⩴
A
c
c
e
s
s
F
i
l
e
S
e
t
,
O
n
e
P
r
i
v
i
l
e
g
e
,
…, AccessFileSet,OnePrivilege,
AccessFileSet
⩴
{
onefile
∈
FileSet
}
∥
morefiles
⊆
FileSet,
OnePrivilege
⩴
P
∣
P
=
Authorize
∥
Update
∥
Modify
∥
Read,
Edges
⩴
E
d
g
e
,
…
,
E
d
g
e,
Edge
⩴
N
o
d
e
1
,
N
o
d
e
2
∣
{
Node
1
.
OneParent
=
Node
2,
Node
1
,
Node
2
∈
NodeSet, Node2.OnePrivilege={Create∥Authorize}},Example 7.
We explain the logic in following example, which follows the sequence number listed in Figure1 (grey nodes are linked leaves).
(1)FileSet=F1,F2,F3. User A (e.g., original user, manager) uploads all three files into Cloud. A’s privilege for all files is Create. A’s login account information for Cloud will be used for all other users, namely, B, C, D, and E.
(2)F1 and F2 are two files that will be edited by a team led by B (B is the leader of team 1, e.g., technical team).
(3)F3 can be edited by B (by herself, e.g., F3 is written by B and will be reported to manager A).
(4)F1 and F2 can only be read by C (C is from another team, e.g., testing team).
(5)F3 can be edited by C (by herself, as F3 is written by C and will be reported to manager A). Note that, hereby F3 can be edited by B and C cooperatively.
(6)B is the team leader. She adds two users into her team, namely, D and E. B assigns D to edit F1, but D cannot update F1. The modification on F1 by D can be reviewed by B and updated by B.
(7)B assigns E to edit F2, but E cannot update F2. The modification on F2 by E will be reviewed by B and updated by B.Figure 1
An example for illustration the logic of setup.


### 4.6. Constraints and Principles

Next, we point out some nontrivial insightful constraints to depict some inner principles in F2AC to evaluate its soundness.Principle 1.
The number of leaves atRoot is one. The total number of leaves (NodeLink, namely, AccessFileSet,OnePrivilege pairs) at a child of Root is upper bounded by FileSet. The upper bound can be achieved, because each one file has one privilege. We will explain how to merge the leaves that have the same privilege. Thus, the number of total possible leaves for a node would be the number of possible privileges (namely, four, they are Authorize, Update, Modify, and Read).Principle 2.
The merging set ofAccessFileSet in leaves at a child of Root is upper bounded by FileSet.Principle 3.
The merging set ofAccessFileSet in leaves at all children of Root is upper bounded by FileSet.Principle 4.
The number of children ofRoot (namely, the number of users added by Root) has no limit. It depends on the editing logic of shared files; thus, the number of members in an initial group could be very large.Principle 5.
The total number of leaves on a child of a node (notRoot) is upper bounded by AccessFileSet in the node’s leaf whose OnePrivilege is Authorize. It is similar to Principle 1.Principle 6.
The merging set ofAccessFileSet in leaves on a child of a node (not Root) is upper bounded by AccessFileSet in the node’s leaf whose OnePrivilege is Authorize. It is similar to Principle 2.Principle 7.
The merging set ofAccessFileSet in leaves at all children of a node (not Root) is upper bounded by AccessFileSet in the node’s leaf whose OnePrivilege is Authorize. It is similar to Principle 3.Principle 8.
The number of children of a node has no limit. It is similar to Principle4.Principle 9.
The birth sequence of nodes in the tree is from an upper layer to a lower layer (for a subtree). That is, the growth of the tree is from upper to lower. Thus, users are added into the tree from upper to lower sequentially.Principle 10.
Usually, a physical person has oneToken (and corresponding UserName). Our scheme has the flexibility that one physical person can be given more than one Token. There is another way to achieve the functionality that more Tokens are held by one physical person. That is, usually Tokens in UserName,Token are distinct for different UserName, but same Token for different UserName will achieve the goal of more Tokens at a physical person. (The reason is that Token is used for the authentication of access control.)Principle 11.
One node cannot have two parents (fathers). That is, if oneUserName with corresponding Token is created and assigned, the UserName will not be reused by other nodes for assigning. This principle will simplify the tree. Nonetheless, the F2AC can also achieve that one node has more than one father. The method is that you add the node at first and let two children’s Token be the same.Principle 12.
The deletion of a user can be done by the deletion of a node. If the node has children (namely, not a leaf node), the deletion of the node will let the node’s father be the node’s children’s father. It seems to replace the team leader. If the node has no children (at lowest layer), the deletion of the node will be done directly. Certainly, the deletion of a node will remove the node’s linked leaves together.Principle 13.
The modification of user’s privilege can be done by modifying theOnePrivilege on the linked leaves of the node. Update, Modify, and Read can be changed into each other among them. Update, Modify, and Read can be changed into Authorize. We reserve the flexibility that Authorize can also be changed into Update, Modify, and Read, but it may need to delete subtree of this node for the consistence of principles.Principle 14.
For simplicity and better understanding, we do not include the further accessing conditions, denoted asC, in the design of linked leaves. Indeed, it is without loss of generality. The C can be considered as an extension of P, as C specifies more requirements in accessing policies. Therefore, NodeLink can be extended into AccessFileSet,OnePrivilege,ExtraConditions if required.


### 4.7. Further Extension for Lightweight

As stated in aforementioned Principle1, linked leaves of a node may be too many. We propose several algorithms to merge leaves in the tree structure or merge records in ACL. We take ACL as an example to describe our algorithms. The algorithm for tree structure can be done accordingly.A
C
L has four tuples File∗,User∗,P,C. We change it into User∗,File∗,P∥C for matching with tree model. Next, we will propose algorithms to accelerate the retrieval delay in ACL (and also in the tree).U
s
e
r
∗
,
F
i
l
e
∗ is cartesian product (simply speaking, many-to-many). File∗,P is many-to-one. User∗×File∗,P is many-to-one. Thus, we can combine files that have the same privilege for a single user as one record to decrease the number of records in ACL (and retrieval delay). It is the so-called AccessFileSet in the tree. For each user (except for original user), there are at most four file sets, as the maximal number of privileges are four (namely, Authorize, Update, Modify, and Read). Thus, the linked leaves for each node will be at most four.If we lookAccessFileSet as a single item in the field File∗, the number of records in ACL can further be decreased by merging users. User∗,File∗×P is cartesian product. As the intersection of AccessFileSet is empty set, File∗×P may be the same for different users. In this situation, those User∗ fields can be combined into one item. This can be looked as the merging of nodes that have the same linked leaves in the tree.The retrieval ofACL can be considered as the traverse in the tree. After a user logs in and presents her token, the node is determined in the tree. The linked leaves can be fast fetched for listing (or looking up) files that can be accessed together with corresponding privileges. Also, the node’s children can be listed for addition and removal, if applicable. Thus, the proposed tree-based model provides critical support for algorithms (and functions) in the access control mechanism.


## 4.1. Basic Setting

There exist two tables for facilitating control mechanism atCloud. We denote them as Cloud⩴ACL,UCL, where ⩴ can be looked as “is defined to.” ACL is used for access control; UCL is used for user authentication.(1)ACL is a table for access control that has four fields File∗,User∗,P,C, where File∗ denotes a file name, User∗ denotes a user name, P denotes a privilege, and C denotes one or more conditions. We denote it as ACL⩴File∗,User∗,P,C.The privileges usually have four types,Create, Update, Modify, and Read, which denote create, update, modify, and read, respectively. Users who are assigned Read privilege can only view files. Users who are assigned Modify can read and modify files but not update files. Users who are assigned Update can read, modify, and update the modified content into files. Users who are assigned Create can read, modify, and update files and, especially, can assign privileges to other users. We denote it as P⩴Create,Update,Modify,Read. The former one is the superset of the latter one. That is, Create contains the privilege Update, Update contains Modify, and Modify contains Read. In shorthand, Read⊂Modify⊂Update⊂Create.Extra conditions (columnC) can include more requirements for access, for example, locations, device MAC addresses, or any other requirements. The default value for it is Null, denoted as ∗. We denote it as C⩴∗,Loc,MAC.(2)UCL is a table for user control that has two fields User∗,Token∗, where User∗ is a username and Token∗ is a password for user authentication. We denoted it as UCL⩴User∗,Token∗.F2AC is composed of the following steps.Step  1 (user: firstly login and upload). For the first time login, UserA can upload one or more than one files into CloudC.Step  2 (user: assign one user and one privilege for one file). Once UserA uploads a file successfully (e.g., FileA1); Cloud will add two records into ACL as follows.Step  2.1. One record is FileA1,UserA,Create,∗ that is added into ACL automatically.Step  2.2. UserA will be asked to set up the access privilege of the file (FileA1) by Cloud. That is, UserA specifies the privilege (e.g., Read) of FileA1 to UserB by checking the options (in user interface) provided by Cloud. The setting results will be stored in ACL. That is, the record FileA1,UserB,Read,∗ is added into ACL.Step  3 (user: assign more users and their privileges for one file).
User
A continues to set up more users and more privileges for this file. Cloud add more records in ACL correspondingly. That is, Step 2.2 will be conducted iteratively for FileA1 for assigning more users and privileges.Step  4 (user: upload more files and assign more users and their privileges for more files). If UserA uploads additional files, for example, FileA2, FileA3, Steps 2 and 3 will be reconducted iteratively for those files by Cloud and UserA.Step  5 (cloud: store records into
A
C
L
). After UserA uploads all files and sets up all options for access control, Cloud will store corresponding records into ACL.Step  6 (user: assign
UCL
).
User
A sets up corresponding token for each user in ACL including herself by checking options (in user interface) provided by Cloud.Step  7 (cloud: store records into
UCL
). After that, Cloud stores corresponding records into UCL. For example, UserA,TokenA,UserB,TokenB,UserC,TokenC.Step  8 (user: send account information and tokens to accessing users).
User
A gives her account and password for Cloud, together with TokenB, to UserB; UserA gives her account and password for Cloud, together with TokenC, to UserC. The account and password of UserB and UserC are the same as those of UserA. The token is used for authentication and distinction of different accessing users.Step  9 (user: secondly login and present token). After UserA logs in to Cloud at the second time, she will be asked for her token by Cloud. The reason is that UserA is in UCL at this time.Step  10 (cloud: retrieve
UCL
and
ACL
). After UserA responds her token, Cloud will retrieve UCL to get the user name, namely UserA. Cloud lists all files for UserA by retrieving ACL according to her privileges.Step  11 (other users: login and present token). After UserB logs in to Cloud, she will be asked for showing her token by Cloud. After UserB responds with her token, Cloud will conduct processes similar to Step 10.Remarks 1.
(1) It is required to separate the authentication for logging in toCloud and the authentication for access control, namely, user name in UCL. It will simplify the implementation and management of user authentication at Cloud. The security of original authentication system of Cloud will not be damaged. It is also easy for UserA to understand (for better user experience) and conduct user addition for file accessing.
(2) In Step2.2, one privilege is already enough, as relationships between privileges are subset (or superset). The highest (or largest) privilege is set for one user aiming at one file.
(3) The conditionC could be extra accessing rules on demand, which is set “∗” in the description for simplicity. Indeed, it can be set as Loc, MAC, and so on. Hereby, C⩴∗,Loc,MAC. C can be considered as the extension of P.
(4) Step8 is usually accomplished offline or out of the channel, which is out of the scope of the scheme.


## 4.2. Notations

The major notations used in the remainder of the paper are listed as follows for better understanding.Cloud: File Storage CloudP: Privilege, P⩴Create,Update,Modify,ReadLogin(Cloud,User∗): User Login Function. Login into Cloud as User∗Upload(File∗): User Upload File Function. Upload file File∗SaveACL(File∗,User∗,P,∗): Cloud Save ACL FunctionSetupACL(File∗,User∗,P,∗): User Setup ACL FunctionSetupUCL(User∗,Token∗): User Setup UCL FunctionSaveUCL(User∗,Token∗): Cloud Save UCL FunctionRequestToken(): Function Request Token by Cloud after User Login Returning Token∗RetrieveUCL(Token∗): UCL Retrieve Function by Cloud, Taking as input Token∗, Returning User∗RetrieveACL(User∗): ACL Retrieve Function by Cloud, Taking as input User∗, Returning File∗,P,C.


## 4.3. Abstract Model

The overall procedures are stated as follows in a shorthand for simplicity and clarity as follows.Abstract Model for F2ACStep  1
User
A
:
Login
(
Cloud
,
User
A
), UserA:Upload(FileA1);Step  2.1
Cloud
:
SaveACL
(
F
i
l
e
A
1
,
U
s
e
r
A
,
C
r
e
a
t
e
,
∗
);Step  2.2
User
A
:
SetupACL
(
F
i
l
e
A
1
,
U
s
e
r
B
,
R
e
a
d
,
∗
),
Cloud
:
SaveACL
(
F
i
l
e
A
1
,
U
s
e
r
B
,
R
e
a
d
,
∗
);Step  3
User
A
:
SetupACL
(
F
i
l
e
A
1
,
U
s
e
r
C
,
M
o
d
i
f
y
,
∗
),
Cloud
:
SaveACL
(
F
i
l
e
A
1
,
U
s
e
r
C
,
M
o
d
i
f
y
,
∗
);
User
A
:
SetupACL
(
F
i
l
e
A
1
,
U
s
e
r
D
,
U
p
d
a
t
e
,
∗
),
Cloud
:
SaveACL
(
F
i
l
e
A
1
,
U
s
e
r
D
,
U
p
d
a
t
e
,
∗
);…Step  4
User
A
:
Upload
(
File
A
2
);
User
A
:
Upload
(
File
A
3
)
;
…Step  5
Redo  Steps  2.1, 2.2, and 3;Step  6
User
A
:
SetupUCL
(
User
B
,
Token
B
)
;
User
A
:
SetupUCL
(
User
C
,
Token
C
)
;Step  7
Cloud
:
SaveUCL
(
U
s
e
r
A
,
T
o
k
e
n
A
);
Cloud
:
SaveUCL
(
U
s
e
r
B
,
T
o
k
e
n
B
);
Cloud
:
SaveUCL
(
U
s
e
r
C
,
T
o
k
e
n
C
);Step  8
Off-line Operations.Step  9
User
A
:
Login
(
Cloud
,
User
A
);Step  10
Cloud
:
Token
A
⇐
RequestToken
(
);
Cloud
:
U
⇐
RetrieveUCL
(
Token
A
);
Cloud
:
File
∗
,
P
,
C
⇐
RetrieveACL
(
U
);Step  11
User
B
:
Login
(
Cloud
,
User
A
);Step  12
Cloud
:
Token
B
⇐
AskToken
(
);
Cloud
:
User
B
⇐
RetrieveUCL
(
Token
B
);
Cloud
:
File
∗
,
P
,
C
⇐
RetrieveACL
(
User
B
);
…Remarks 2.
(1) In Step1, UserA logs in for file uploading. After this login, UCL is created. In UserA’s next login (e.g., in Step 9), UserA will be requested for her token. If this time no file is uploaded, UCL will not be created. That is, once a file is uploaded by a user, UCL and ACL will be created at Cloud.
(2) In Step11, if a user (e.g., UserX) logs in via not using UserA’s account (including user name and password), Cloud will respond that this user (namely, UserX) is not a file sharing user related to UserA. It is an independent login, not being related to the file sharing of UserA (i.e., this login may be used for UserX’s file uploading and sharing).
In contrast, ifUserA logs in with UserB’s account, instead of UserA’s, UserA will be regarded as UserB’s file sharer and be requested for showing the token that is set by UserB.
(3) Usually,Create can be only assigned to the user who uploads the file into Cloud, by Cloud automatically in Step 2.1. In the following sections we will extend it for more flexible functions in more complicated application scenarios.


## 4.4. Extension for Flexibility

In the above abstract model, the major steps for F2AC are described. In this setting, only user that uploads the file can obtainCreate privilege and can authorize privileges to others. It can simplify the management of privileges, but it may not be convenient when the file is shared in a dynamic group whose members are changed frequently, or a group with a large number of users or different layers.For example,UserA uploads FileA, but UserA is willing to let UserB be a proxy of her for managing the file editing. Thus, UserA hopes that UserB can authorize privileges to other users as a team leader and represent as a proxy of UserA; for example, UserB can further assign privilege such as Read to UserC. To extend this flexibility, we propose an extension of basic settings and abstract model.Firstly,P⩴Create,Update,Modify,Read in basic settings will be extended to P⩴Create,Authorize,Update,Modify,Read. That is, the user with Authorize privilege will be able to authorize privileges to other users like UserA. Certainly, Authorize is a superset of Update, Modify, and Read.Secondly, in abstract model after Step12, if P that is returned by RetrieveACL(UserB) is Authorize, UserB will be able to set up ACL. Four policies are proposed hereby on methods for setting up ACL in the following.Policy 1 (none-transitiveAuthorize privilege and none-additive users).
AfterUserB with the privilege Authorize logs in into Cloud as UserA, all files are listed. UserB selects a file, for example, FileA1, and the related users and their privileges are listed. UserB can change those privileges that are Update, Modify, and Read. That is, only the user with Create can assign Authorize privilege; the user with Authorize cannot assign Authorize privilege to others but can change privileges such as Update, Modify, and Read. After any chance happens, ACL will be updated for column P for corresponding records.Policy 2 (none-transitive ofAuthorize privilege and additive users).
The difference between this policy and Policy1 is that the user with Authorize privilege can add more users for current files. If so, ACL will not only be updated at column P, but also be appended more records.
If the trace back on who adds the user into the group is required,ACL will be extended to File∗,User∗,P,C,ByWhom. ByWhom will record the user who adds User∗. For example, if UserA adds UserB into ACL, ByWhom will be UserA. If UserB with privilege Authorize adds UserC into ACL, ByWhom in this row will be set as UserB.
If a new user is appended intoACL, this user must be appended into UCL. The token of the new user is set up by the user who adds the new user. For example, if UserB with privilege Authorize adds UserC into ACL, UserB should set up UserC,TokenC in UCL.
The deletion of users inACL is only permitted by the user who matches ByWhom in this row. That is, if ByWhom is UserA in this row in ACL, only UserA can delete this row (namely, the user) from ACL (by user interface provided by Cloud). Once a user is deleted in ACL, the user will be also deleted in UCL automatically. For example, if ProjectColumn(ACL,User∗)!=UserB (i.e., all records like File∗,UserB,∗,∗,ByWhom=UserA are deleted in ACL by UserA), UserB,TokenB will be deleted from UCL.Policy 3 (transitive ofAuthorize privilege and nonadditive users).
The difference between this policy and Policy1 is that the user with Authorize privilege can change privileges Update,Modify, and Read into Authorize in ACL. That is, not only the user with Create can assign Authorize privilege, but also the user with Authorize can assign Authorize privilege to others. If so, the column P in ACL will not only be updated among Update,Modify, and Read, but also be updated from Update, Modify, and Read into Authorize. However, the user with Authorize privilege cannot add more users for current files, namely, nonadditive users.Policy 4 (transitive ofAuthorize privilege and additive users).
This one will be most complicated and flexible. It combines functions in Policies2 and 3. That is, the user with Authorize can assign Authorize privilege to others, and the user with Authorize privilege can also add more users for current shared files.Remarks 3.
(1) Each user has only one possibleByWhom in ACL. Once a user is added into ACL, the ByWhom field will be set. For better understanding, if we consider ByWhom as a parent (namely, father) and consider each user as a node, user graph will be considered as a directed tree. The direction is from a child or all children to the father. Recall that, for user deletion, only the father can delete directed child or children in the tree (if user B’s ByWhom in ACL is user A who currently logs in to Cloud, user A will be presented an option on whether deleting B or not in user interface).
Note that, for consistence, if a none-leaf node is deleted, the node’s all children will replace their fathers by the node’s father. (All children’sByWhom will be replaced by the node’s ByWhom.)
(2) A user’s privilege for a file can be modified by anyone who hasCreate or Authorize privilege for this file. For better understanding, we can look users with Creat and Authorize for a file as team leaders for this file. Other users with privileges such as Update, Modify, or Read for this file will be considered as group members for this file.
(3) Once a user is added intoACL, she will be added into UCL. The same user name presents only once in UCL. For better understanding, all users in UCL can be considered as a group whose members share the same login account information (namely, login user name and password) in Cloud as the original user who uploads shared files.
(4) For each file, only one user can haveCreate privilege. The user who has Create privilege is the original user (the one who uploads the file into Cloud). All users in UCL will share the same account information with this user who has Create privilege.
(5) A user’s father (according toByWhom field) has responsibility to deliver the account information and token to the user, usually offline.


## 4.5. Directed Tree with Linked Leaf Model

Policy4 is the most flexible (or powerful) one in all policies for file sharing in a dynamic group or a group with a large number of members. Intuitively, someone may suspect that this policy may result in some inconsistency due to the complexity of user addition, deletion, and transitive authorization. To make it clear, we propose a concept and implementation model for F2AC, which presents as a directed tree with linked leaf (leaves).(1) Users are organized in a tree structure. Each user presents as one node at the tree. The root of the tree is the user who uploads all current sharing files, namely, one who hasCreate privilege for those files. All users in the tree share the same login account information as the root, but they are distinguished via their tokens.(2) Each nonroot node has one parent (namely, father). Anyone of these nodes has a directed edge pointed to its father. The father is the user who adds a child node or children nodes in the tree. Only users who haveAuthenticate or Create privilege can add a child or children. The father of a child can be fetched from ACL by looking up ByWhom column.(3) Each node has three properties, namely,UserName,Token,OneParent. UserName and Token are assigned by node’s father. The property OneParent points to node’s father.(4) Each node links to one or multiple properties, calledNodeLink. Each link has two related properties. One is AccessFileSet; the other is OnePrivilege. AccessFileSet property is a set consisting of one or more files; OnePrivilege property is one privilege for files in AccessFileSet. Each node may have more than one AccessFileSet, but each AccessFileSet has one corresponding OnePrivilege (namely, the largest privilege). That is, each node links to one or more sets that represent access files, and each set has one bit to represent the privilege for this set. We look on one or multiple properties as linked leaf (leaves) for this node. The model is thus called a tree with linked leaf (leaves). Note that linked leaf is not a leaf node; leaf node is a node that has no child, but linked leaf is a property for every node.(5) The file set (usually consisting of multiple files) at the father node should be the superset of that (namely, file set) at a child node or children. It is nontrivial to be aware of but can be understood for the reason that father’s files are reassigned to a child or children to edit. Thus, a merging set of a child’s or children’sAccessFileSet is upper-bounded by the father’s AccessFileSet.(6)ACL and UCL can be constructed by the above tree model. The retrieval of ACL and UCL can be accomplished by underlying tree data structures and algorithms.We denote the tree model in the following.Directed Tree with Linked Leaf Model
Tree
⩴
Root
,
NodeSet
,
Edges,
FileSet
⩴
files
∣
uploadedbyRoot,
Root
⩴
UserName
,
Token
,
OneParent
=
NULL
,
RootLink,
RootLink
⩴
AccessFileSet
=
FileSet
,
OnePrivilege
=
Create,
NodeSet
⩴
N
o
d
e
,
…
,
N
o
d
e
Node
⩴
U
s
e
r
N
a
m
e
,
T
o
k
e
n
,
O
n
e
P
a
r
e
n
t
,
N
o
d
e
L
i
n
k,
NodeLink
⩴
A
c
c
e
s
s
F
i
l
e
S
e
t
,
O
n
e
P
r
i
v
i
l
e
g
e
,
…, AccessFileSet,OnePrivilege,
AccessFileSet
⩴
{
onefile
∈
FileSet
}
∥
morefiles
⊆
FileSet,
OnePrivilege
⩴
P
∣
P
=
Authorize
∥
Update
∥
Modify
∥
Read,
Edges
⩴
E
d
g
e
,
…
,
E
d
g
e,
Edge
⩴
N
o
d
e
1
,
N
o
d
e
2
∣
{
Node
1
.
OneParent
=
Node
2,
Node
1
,
Node
2
∈
NodeSet, Node2.OnePrivilege={Create∥Authorize}},Example 7.
We explain the logic in following example, which follows the sequence number listed in Figure1 (grey nodes are linked leaves).
(1)FileSet=F1,F2,F3. User A (e.g., original user, manager) uploads all three files into Cloud. A’s privilege for all files is Create. A’s login account information for Cloud will be used for all other users, namely, B, C, D, and E.
(2)F1 and F2 are two files that will be edited by a team led by B (B is the leader of team 1, e.g., technical team).
(3)F3 can be edited by B (by herself, e.g., F3 is written by B and will be reported to manager A).
(4)F1 and F2 can only be read by C (C is from another team, e.g., testing team).
(5)F3 can be edited by C (by herself, as F3 is written by C and will be reported to manager A). Note that, hereby F3 can be edited by B and C cooperatively.
(6)B is the team leader. She adds two users into her team, namely, D and E. B assigns D to edit F1, but D cannot update F1. The modification on F1 by D can be reviewed by B and updated by B.
(7)B assigns E to edit F2, but E cannot update F2. The modification on F2 by E will be reviewed by B and updated by B.Figure 1
An example for illustration the logic of setup.


## 4.6. Constraints and Principles

Next, we point out some nontrivial insightful constraints to depict some inner principles in F2AC to evaluate its soundness.Principle 1.
The number of leaves atRoot is one. The total number of leaves (NodeLink, namely, AccessFileSet,OnePrivilege pairs) at a child of Root is upper bounded by FileSet. The upper bound can be achieved, because each one file has one privilege. We will explain how to merge the leaves that have the same privilege. Thus, the number of total possible leaves for a node would be the number of possible privileges (namely, four, they are Authorize, Update, Modify, and Read).Principle 2.
The merging set ofAccessFileSet in leaves at a child of Root is upper bounded by FileSet.Principle 3.
The merging set ofAccessFileSet in leaves at all children of Root is upper bounded by FileSet.Principle 4.
The number of children ofRoot (namely, the number of users added by Root) has no limit. It depends on the editing logic of shared files; thus, the number of members in an initial group could be very large.Principle 5.
The total number of leaves on a child of a node (notRoot) is upper bounded by AccessFileSet in the node’s leaf whose OnePrivilege is Authorize. It is similar to Principle 1.Principle 6.
The merging set ofAccessFileSet in leaves on a child of a node (not Root) is upper bounded by AccessFileSet in the node’s leaf whose OnePrivilege is Authorize. It is similar to Principle 2.Principle 7.
The merging set ofAccessFileSet in leaves at all children of a node (not Root) is upper bounded by AccessFileSet in the node’s leaf whose OnePrivilege is Authorize. It is similar to Principle 3.Principle 8.
The number of children of a node has no limit. It is similar to Principle4.Principle 9.
The birth sequence of nodes in the tree is from an upper layer to a lower layer (for a subtree). That is, the growth of the tree is from upper to lower. Thus, users are added into the tree from upper to lower sequentially.Principle 10.
Usually, a physical person has oneToken (and corresponding UserName). Our scheme has the flexibility that one physical person can be given more than one Token. There is another way to achieve the functionality that more Tokens are held by one physical person. That is, usually Tokens in UserName,Token are distinct for different UserName, but same Token for different UserName will achieve the goal of more Tokens at a physical person. (The reason is that Token is used for the authentication of access control.)Principle 11.
One node cannot have two parents (fathers). That is, if oneUserName with corresponding Token is created and assigned, the UserName will not be reused by other nodes for assigning. This principle will simplify the tree. Nonetheless, the F2AC can also achieve that one node has more than one father. The method is that you add the node at first and let two children’s Token be the same.Principle 12.
The deletion of a user can be done by the deletion of a node. If the node has children (namely, not a leaf node), the deletion of the node will let the node’s father be the node’s children’s father. It seems to replace the team leader. If the node has no children (at lowest layer), the deletion of the node will be done directly. Certainly, the deletion of a node will remove the node’s linked leaves together.Principle 13.
The modification of user’s privilege can be done by modifying theOnePrivilege on the linked leaves of the node. Update, Modify, and Read can be changed into each other among them. Update, Modify, and Read can be changed into Authorize. We reserve the flexibility that Authorize can also be changed into Update, Modify, and Read, but it may need to delete subtree of this node for the consistence of principles.Principle 14.
For simplicity and better understanding, we do not include the further accessing conditions, denoted asC, in the design of linked leaves. Indeed, it is without loss of generality. The C can be considered as an extension of P, as C specifies more requirements in accessing policies. Therefore, NodeLink can be extended into AccessFileSet,OnePrivilege,ExtraConditions if required.


## 4.7. Further Extension for Lightweight

As stated in aforementioned Principle1, linked leaves of a node may be too many. We propose several algorithms to merge leaves in the tree structure or merge records in ACL. We take ACL as an example to describe our algorithms. The algorithm for tree structure can be done accordingly.A
C
L has four tuples File∗,User∗,P,C. We change it into User∗,File∗,P∥C for matching with tree model. Next, we will propose algorithms to accelerate the retrieval delay in ACL (and also in the tree).U
s
e
r
∗
,
F
i
l
e
∗ is cartesian product (simply speaking, many-to-many). File∗,P is many-to-one. User∗×File∗,P is many-to-one. Thus, we can combine files that have the same privilege for a single user as one record to decrease the number of records in ACL (and retrieval delay). It is the so-called AccessFileSet in the tree. For each user (except for original user), there are at most four file sets, as the maximal number of privileges are four (namely, Authorize, Update, Modify, and Read). Thus, the linked leaves for each node will be at most four.If we lookAccessFileSet as a single item in the field File∗, the number of records in ACL can further be decreased by merging users. User∗,File∗×P is cartesian product. As the intersection of AccessFileSet is empty set, File∗×P may be the same for different users. In this situation, those User∗ fields can be combined into one item. This can be looked as the merging of nodes that have the same linked leaves in the tree.The retrieval ofACL can be considered as the traverse in the tree. After a user logs in and presents her token, the node is determined in the tree. The linked leaves can be fast fetched for listing (or looking up) files that can be accessed together with corresponding privileges. Also, the node’s children can be listed for addition and removal, if applicable. Thus, the proposed tree-based model provides critical support for algorithms (and functions) in the access control mechanism.


## 5. Conclusions

In this paper, we proposed a lightweight, fine-grained, and flexible scheme, called F2AC, for access control in multiple-party file editing and sharing in mobile cloud computing. F2AC can support dynamically adding and deleting users in an ad hoc group, privilege self-defining as a creator’s proxy or team leader, transitively authorizing privileges for members in subteams, transitively revoking privileges, and separating of access authentication from system authentication. The directed tree with linked leaf (leaves) model is proposed for lightweight implementation and verification. The leaf merging and node merging are described for lightweight storage and fast retrieval of privileges. The future work could be the evaluation of linked leaf model in some mainstream cloud services such as Apple iCloud, Baidu Cloud, and Alibaba Cloud.



---

*Source: 5232846-2016-01-21.xml*