Lan Zhou, Vijay Varadharajan, and Michael Hitchens Trust Enhanced Cryptographic Role-Based Access Control for Secure Cloud Data Storage Lan Zhou, Vijay Varadharajan, and Michael Hitchens

Introduction

Introduction Protect the privacy of data stored in the cloud System structure Role-based access control (RBAC) schemes Ensure data can only be accessed by those who have access permissions Roles are used to associate users with permissions on resources Do not address the issues of trust

Contributions Owner-Role RBAC Role-User RBAC Role Inheritance Owner gives permission a role Role-User RBAC Role grants membership to a user Role Inheritance Trustworthiness affected by historical performance of ancestor role and descendent role E.g. Role A inherits all permissions that role B has

Preliminaries Experience-Based Trust Beta distribution Probability next transaction is positive Most Bayesian trust systems assume 𝛼=𝛽=1

Preliminaries Role-Based Encryption Scheme Entities: SA, system administrator, manage the role hierarchy structure RM, role manager, manager user membership of a role Users, who want to access and decrypt the stored data Owners, stored encrypted data in the cloud, and define RB access policies

Preliminaries Role-Based Encryption Scheme Inheritance: {U1, U2, U3} Owner encrypt a message M to R3 Encryption algorithm. Inputs: system public key pk, role public parameters pub(R3) of R3, M U1 wants to access M Decryption algorithm. Inputs: pk, user decryption key dk(U1) and ciphertext C {U1, U2, U3}

Trust Issues in using Cryptographic RBAC Schemes in Secure Cloud Storage

Trust Issues Owners → Trust of Role Manager Secure their data Role Manager → Trust of Users Make Owners trust these Role

Data Owners’ Trust in Role Managers Owners are the parties who want to share the data, and reduce the risks of unauthorized parties accessing their data A trusted role manager should meet following requirements: Role managers should grant membership to users who are qualified for that role Role managers should not grant membership to users who are not qualified for that role Qualified users in a role should not leak the data to unqualified users Role managers of ancestor roles of the role under consideration should be trusted

Role Managers’ Trust in Data Users Role managers manage their user memberships, and build up their own reputation A trusted user should meet the following requirements: User should not be involved in the event of leaking resources of the role User should be considered as trusted by role managers of any role of which the user is or was a member

Owner-Role RBAC Trust Model

Three Entities Three entities – Owner, User, and Role Owner is the entity who owns the data and stores it in an encrypted form in the cloud User is the entity who wishes to access the data from the cloud Role is the entity that associates users with the access to owners’ data, and each role manages the user membership of itself

Interactions Interactions: From an owner’s perspective, an interaction is a transaction whereby an owner encrypts data to a role, and the role gives the access to the data to qualified users A successful interaction is an interaction where only qualified users in the role to which data is encrypted or users in the ancestor roles of the role have accessed the data An unsuccessful interaction is an interaction where an unqualified user has accessed the data

Unsuccessful Interactions Two types of unsuccessful interactions User Management Failure: User management failure is an unsuccessful interaction caused by a role who did not manage the user membership properly User Behavior Failure: User behavior failure is an unsuccessful interaction where the data is leaked to unqualified users

Trust Vector Define a trust vector to represent the behavior history of a role: 𝑟 is the value related to successful interactions 𝑠 𝑀 is the value related to the User Management Failure 𝑠 𝐵 is the value related to User Behavior Failure

Trust Function Define the trust function 𝑇(𝑣) that represents the trust value derived from the trust vector 𝑣 as:

Interaction History Define the interaction history derived from ratings of a role 𝑅 as: Each entry 𝐻 𝑖 𝑅 is defined as a pair of parameters 𝐻 𝑖 𝑅 = 𝐼𝐷 𝑖 , 𝑣 𝑖, 𝑅

Trust Evaluation When an owner evaluates the trust of a role 𝑅, the owner needs to consider the following different trust classes Individual Trust: Individual trust is a belief that is derived directly from the interaction history of the role 𝑅 Inheritance Trust: Inheritance trust is a belief that is derived from the interaction history of other roles that have inheritance relationships with the role 𝑅 Combination Trust: To combine these two types of trusts together

Individual Trust The individual trust value of the role 𝑅 is computed as:

Inheritance Trust User Behavior Failure: All its descendant roles needs to be considered Assume a descendant role 𝑅 𝑑 of a role 𝑅, the feedback that the owner provided should not only be applied to that descendant role 𝑅 𝑑 , but should also affect the trust of 𝑅 User Management Failure is not considered in inheritance trust

Inheritance Trust The inheritance trust value derived from the descendant roles is computed as:

Combination Trust To combine these two types of trusts together The combination trust of the role will be the minimum value of the trust of this role and the trust of all its ancestor roles

Owner-Role RBAC Trust Model Example

Owner-Role RBAC Trust Model Example

Role-User RBAC Trust Model

Trust Model Since the trustworthiness of a role is primarily determined by the behavior of users of the role, it is important for the role to ensure that only users with good behavior are granted membership This trust model aims to assist a role to determine the trust of users who belong to the role or want to join the role

Trust Vector Since there is no interaction between the roles and users, define a trust vector to represent directly the behavior history of a user as follows: ℎ is the total number of resources that have been assigned to the role 𝑠 is the value related to the leaking events that the user was involved in

Trust Function and Trust Record Each entry 𝐻 𝑖 𝑈 is defined as a pair of parameters 𝐻 𝑖 𝑈 = 𝑅 𝑖 , 𝑣 𝑖, 𝑈

Trust Evaluation Direct Trust: Direct trust of a role on a user 𝑈 is the belief that is derived directly from trust records of the user 𝑈 from the role itself Recommended Trust: Recommended trust is the belief that is derived from the trust records of the user from other roles in the system

Trust Evaluation Combination Trust: To combine these two types of trust together

Role-User RBAC Trust Model Example

Role-User RBAC Trust Model Example

Architecture & Application Scenario

ARCHITECTURE Basic cryptographic RABC scheme Extra trust management system

ARCHITECTURE Owners encrypt a resource to a role Get the trust value of that role by channel 13. Encrypt and upload data to cloud (channel 3). Report resource ID and role ID to role behavior auditor (channel 9). The auditor updates the number of accessible resources for this role via channel 10. Owners find a leakage of resource. Report to role behavior auditor via channel 9. Auditor forward to central repository (channel 10).

ARCHITECTURE Negative feedback of a role is raised Send resource ID to user behavior auditor (channel 7). The auditor update the trust records of users who have accessed this resource (channel 8). Update of user membership Role request trust value for a user (channel 12). Update the role parameters via channel 2.

APPLICATION SCENARIO An organization consists of two branches, and each branch consists of several departments. The head office has two head departments 𝑀𝐷 and 𝑃𝐷 which manage the relevant departments in both branches.

APPLICATION SCENARIO No publisher has ever interacted with the role 𝑃𝐷 1 , 𝑃𝐷 2 . 𝐵 1 , 𝑀𝐷 1 , 𝑃𝐷 1 are the same as 𝐵 2 , 𝑀𝐷 2 , 𝑃𝐷 2 in terms of the number of employees. Percentage of good feedbacks for 𝐵 1 is higher than that for 𝐵 2 .

APPLICATION SCENARIO Role 𝑂𝑅𝐺 has only good feedback Good feedback percentage for 𝐵 2 is low Role 𝑀𝐷 1 has only good feedback Resource subscribed by 𝐵 1 leaks The system cannot determine the malicious user System assists role 𝐵 2 to warn or exclude potential malicious users

CONCLUSION Trust models are proposed to assist owners and roles to create flexible access policies, and cryptographic RBAC schemes ensure that these policies are enforced in the cloud. Owners and users can determine the trustworthiness of individual roles and users respectively. Role inheritance and hierarchy are considered in the evaluation of trustworthiness of roles.

Q&A Thank you!