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.
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 (called ) uploads a file into a storage cloud. She tells the other two users (called and ) user name and password for logging into the storage cloud. and can use the user name and password to successfully log into the storage cloud and access the file, like . In other words, , , and 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. Section 2 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 entity who uploads files and shares those files, an entity who is asked to access these files, and a storage server who is at cloud side. Simply speaking, uploads files into . gives login account information to . logs in and accesses files according to her privilege that is set by .
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 by 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 at . We denote them as , where can be looked as “is defined to.” is used for access control; is used for user authentication.
(1) is a table for access control that has four fields , where denotes a file name, denotes a user name, denotes a privilege, and denotes one or more conditions. We denote it as .
The privileges usually have four types, , , , and , which denote create, update, modify, and read, respectively. Users who are assigned privilege can only view files. Users who are assigned can read and modify files but not update files. Users who are assigned can read, modify, and update the modified content into files. Users who are assigned can read, modify, and update files and, especially, can assign privileges to other users. We denote it as . The former one is the superset of the latter one. That is, contains the privilege , contains , and contains . In shorthand,
Extra conditions (column ) 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 .
(2) is a table for user control that has two fields , where is a username and is a password for user authentication. We denoted it as .
F2AC is composed of the following steps.
Step 1 (user: firstly login and upload). For the first time login, can upload one or more than one files into .
Step 2 (user: assign one user and one privilege for one file). Once uploads a file successfully (e.g., ); will add two records into as follows.
Step 2.1. One record is that is added into automatically.
Step 2.2. will be asked to set up the access privilege of the file () by . That is, specifies the privilege (e.g., ) of to by checking the options (in user interface) provided by . The setting results will be stored in . That is, the record is added into .
Step 3 (user: assign more users and their privileges for one file). continues to set up more users and more privileges for this file. add more records in correspondingly. That is, Step will be conducted iteratively for for assigning more users and privileges.
Step 4 (user: upload more files and assign more users and their privileges for more files). If uploads additional files, for example, , , Steps and will be reconducted iteratively for those files by and .
Step 5 (cloud: store records into ). After uploads all files and sets up all options for access control, will store corresponding records into .
Step 6 (user: assign ). sets up corresponding token for each user in including herself by checking options (in user interface) provided by .
Step 7 (cloud: store records into ). After that, stores corresponding records into . For example, .
Step 8 (user: send account information and tokens to accessing users). gives her account and password for , together with , to ; gives her account and password for , together with , to . The account and password of and are the same as those of . The token is used for authentication and distinction of different accessing users.
Step 9 (user: secondly login and present token). After logs in to at the second time, she will be asked for her token by . The reason is that is in at this time.
Step 10 (cloud: retrieve and ). After responds her token, will retrieve to get the user name, namely . lists all files for by retrieving according to her privileges.
Step 11 (other users: login and present token). After logs in to , she will be asked for showing her token by . After responds with her token, will conduct processes similar to Step .
Remarks 1. (1) It is required to separate the authentication for logging in to and the authentication for access control, namely, user name in . It will simplify the implementation and management of user authentication at . The security of original authentication system of will not be damaged. It is also easy for to understand (for better user experience) and conduct user addition for file accessing.
(2) In Step , 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 condition could be extra accessing rules on demand, which is set “” in the description for simplicity. Indeed, it can be set as , , and so on. Hereby, . can be considered as the extension of .
(4) Step 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 Cloud : Privilege, ): User Login Function. Login into as : User Upload File Function. Upload file : Cloud Save ACL Function : User Setup ACL Function : User Setup UCL Function : Cloud Save UCL Function : Function Request Token by Cloud after User Login Returning : UCL Retrieve Function by Cloud, Taking as input , Returning : ACL Retrieve Function by Cloud, Taking as input , Returning .
4.3. Abstract Model
The overall procedures are stated as follows in a shorthand for simplicity and clarity as follows.
Abstract Model for F2AC
Step 1 , ;
Step 2.1 ;
Step 2.2 , ;
Step 3 , ; , ;
Step 4 ;
Step 5 Redo Steps 2.1, 2.2, and 3;
Step 6
Step 7 ; ; ;
Step 8 Off-line Operations.
Step 9 ;
Step 10 ; ; ;
Step 11 ;
Step 12 ; ; ;
Remarks 2. (1) In Step , logs in for file uploading. After this login, is created. In ’s next login (e.g., in Step ), will be requested for her token. If this time no file is uploaded, will not be created. That is, once a file is uploaded by a user, and will be created at .
(2) In Step , if a user (e.g., ) logs in via not using ’s account (including user name and password), will respond that this user (namely, ) is not a file sharing user related to . It is an independent login, not being related to the file sharing of (i.e., this login may be used for ’s file uploading and sharing).
In contrast, if logs in with ’s account, instead of ’s, will be regarded as ’s file sharer and be requested for showing the token that is set by .
(3) Usually, can be only assigned to the user who uploads the file into , by automatically in Step . 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 obtain 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, uploads , but is willing to let be a proxy of her for managing the file editing. Thus, hopes that can authorize privileges to other users as a team leader and represent as a proxy of ; for example, can further assign privilege such as to . To extend this flexibility, we propose an extension of basic settings and abstract model.
Firstly, in basic settings will be extended to . That is, the user with privilege will be able to authorize privileges to other users like . Certainly, is a superset of , and .
Secondly, in abstract model after Step , if that is returned by is , will be able to set up . Four policies are proposed hereby on methods for setting up in the following.
Policy 1 (none-transitive privilege and none-additive users). After with the privilege logs in into as , all files are listed. selects a file, for example, , and the related users and their privileges are listed. can change those privileges that are , and . That is, only the user with can assign privilege; the user with cannot assign privilege to others but can change privileges such as , , and . After any chance happens, will be updated for column for corresponding records.
Policy 2 (none-transitive of privilege and additive users). The difference between this policy and Policy 1 is that the user with privilege can add more users for current files. If so, will not only be updated at column , but also be appended more records.
If the trace back on who adds the user into the group is required, will be extended to . will record the user who adds . For example, if adds into , will be . If with privilege adds into , in this row will be set as .
If a new user is appended into , this user must be appended into . The token of the new user is set up by the user who adds the new user. For example, if with privilege adds into , should set up in .
The deletion of users in is only permitted by the user who matches in this row. That is, if is in this row in , only can delete this row (namely, the user) from (by user interface provided by ). Once a user is deleted in , the user will be also deleted in automatically. For example, if (i.e., all records like are deleted in by ), will be deleted from .
Policy 3 (transitive of privilege and nonadditive users). The difference between this policy and Policy 1 is that the user with privilege can change privileges , , and into in . That is, not only the user with can assign privilege, but also the user with can assign privilege to others. If so, the column in will not only be updated among , and , but also be updated from , , and into . However, the user with privilege cannot add more users for current files, namely, nonadditive users.
Policy 4 (transitive of privilege and additive users). This one will be most complicated and flexible. It combines functions in Policies 2 and 3. That is, the user with can assign privilege to others, and the user with privilege can also add more users for current shared files.
Remarks 3. (1) Each user has only one possible in . Once a user is added into , the field will be set. For better understanding, if we consider 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 ’s in is user who currently logs in to , user will be presented an option on whether deleting 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’s will be replaced by the node’s .)
(2) A user’s privilege for a file can be modified by anyone who has or privilege for this file. For better understanding, we can look users with and for a file as team leaders for this file. Other users with privileges such as , , or for this file will be considered as group members for this file.
(3) Once a user is added into , she will be added into . The same user name presents only once in . For better understanding, all users in can be considered as a group whose members share the same login account information (namely, login user name and password) in as the original user who uploads shared files.
(4) For each file, only one user can have privilege. The user who has privilege is the original user (the one who uploads the file into ). All users in will share the same account information with this user who has privilege.
(5) A user’s father (according to field) has responsibility to deliver the account information and token to the user, usually offline.
4.5. Directed Tree with Linked Leaf Model
Policy 4 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 has 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 have or privilege can add a child or children. The father of a child can be fetched from by looking up column.
(3) Each node has three properties, namely, . and are assigned by node’s father. The property points to node’s father.
(4) Each node links to one or multiple properties, called . Each link has two related properties. One is ; the other is . property is a set consisting of one or more files; property is one privilege for files in . Each node may have more than one , but each has one corresponding (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’s is upper-bounded by the father’s .
(6) and can be constructed by the above tree model. The retrieval of and can be accomplished by underlying tree data structures and algorithms.
We denote the tree model in the following.
Directed Tree with Linked Leaf Model , , , , , , , , , , , , ,
Example 7. We explain the logic in following example, which follows the sequence number listed in Figure 1 (grey nodes are linked leaves).
(1) . User (e.g., original user, manager) uploads all three files into . ’s privilege for all files is . ’s login account information for will be used for all other users, namely, , , , and .
(2) and are two files that will be edited by a team led by ( is the leader of team 1, e.g., technical team).
(3) can be edited by (by herself, e.g., is written by and will be reported to manager ).
(4) and can only be read by ( is from another team, e.g., testing team).
(5) can be edited by (by herself, as is written by and will be reported to manager ). Note that, hereby can be edited by and cooperatively.
(6) is the team leader. She adds two users into her team, namely, and . assigns to edit , but cannot update . The modification on by can be reviewed by and updated by .
(7) assigns to edit , but cannot update . The modification on by will be reviewed by and updated by .
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 at is one. The total number of leaves (, namely, pairs) at a child of is upper bounded by . 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 , , , and ).
Principle 2. The merging set of in leaves at a child of is upper bounded by .
Principle 3. The merging set of in leaves at all children of is upper bounded by .
Principle 4. The number of children of (namely, the number of users added by ) 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 (not ) is upper bounded by in the node’s leaf whose is . It is similar to Principle 1.
Principle 6. The merging set of in leaves on a child of a node (not ) is upper bounded by in the node’s leaf whose is . It is similar to Principle 2.
Principle 7. The merging set of in leaves at all children of a node (not ) is upper bounded by in the node’s leaf whose is . It is similar to Principle 3.
Principle 8. The number of children of a node has no limit. It is similar to Principle 4.
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 one (and corresponding ). Our scheme has the flexibility that one physical person can be given more than one . There is another way to achieve the functionality that more s are held by one physical person. That is, usually s in are distinct for different , but same for different will achieve the goal of more s at a physical person. (The reason is that is used for the authentication of access control.)
Principle 11. One node cannot have two parents (fathers). That is, if one with corresponding is created and assigned, the 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 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 the on the linked leaves of the node. , , and can be changed into each other among them. , , and can be changed into . We reserve the flexibility that can also be changed into , , and , 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 as , in the design of linked leaves. Indeed, it is without loss of generality. The can be considered as an extension of , as specifies more requirements in accessing policies. Therefore, can be extended into if required.
4.7. Further Extension for Lightweight
As stated in aforementioned Principle 1, linked leaves of a node may be too many. We propose several algorithms to merge leaves in the tree structure or merge records in . We take as an example to describe our algorithms. The algorithm for tree structure can be done accordingly.
has four tuples . We change it into for matching with tree model. Next, we will propose algorithms to accelerate the retrieval delay in (and also in the tree).
is cartesian product (simply speaking, many-to-many). is many-to-one. 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 (and retrieval delay). It is the so-called 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, , , , and ). Thus, the linked leaves for each node will be at most four.
If we look as a single item in the field , the number of records in can further be decreased by merging users. is cartesian product. As the intersection of is empty set, may be the same for different users. In this situation, those 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 of 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.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgments
The research was financially supported by the National Natural Science Foundation of China under Grant nos. 61170217, 61502440, 61301166, and 61363069, the Fundamental Research Funds for the Central Universities, and China University of Geosciences (Wuhan) (Grants nos. CUGL150831 and CUGL150416).