1. 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

2. Introduction

3. 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

4. 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

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

6. 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

7. 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}

8. Trust Issues in using Cryptographic RBAC Schemes in Secure Cloud Storage

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

10. 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

11. 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

12. Owner-Role RBAC Trust Model

13. 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

14. 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

15. 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

16. 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

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

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

19. 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

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

21. 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

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

23. 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

24. Owner-Role RBAC Trust Model Example

25. Owner-Role RBAC Trust Model Example

26. Role-User RBAC Trust Model

27. 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

28. 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

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

30. 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

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

32. Role-User RBAC Trust Model Example

33. Role-User RBAC Trust Model Example

34. Architecture & Application Scenario

35. ARCHITECTURE Basic cryptographic RABC scheme
Extra trust management system

36. 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).

37. 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.

38. 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.

39. 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 .

40. 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

41. 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.

42. Q&A
Thank you!