Trust-based Secure Cloud Data Storage with Cryptographic Role-based

Access Control

Lan Zhou, Vijay Varadharajan and Michael Hitchens

Information and Networked Systems Security Research, Department of Computing, Macquarie University,

North Ryde, NSW, Australia

Keywords:

Role-based Access Control, Trust Model, Cryptographic RBAC.

Abstract:

Role-based access control (RBAC) model is a widely used access control model which can simplify security

management in large-scale systems. Recently, several cryptographic RBAC schemes have been proposed to

integrate cryptographic techniques with RBAC models to secure data storage in an outsourced environment

such as a cloud. These schemes allow data to be encrypted in such a way that only the users who are members

of an appropriate role can decrypt and view the data. However, the issue of trust in such a data storage system

is not addressed in these schemes. In this paper, we propose trust models to improve the security of such a

system which uses cryptographic RBAC schemes. The trust models provide an approach for the users and

roles to determine the trustworthiness of individual roles and owners in the RBAC system. The users can use

the trust models to decide whether to join a particular role for accessing data in the system. The roles can use

the trust models in their decision to ensure that only data from data owners with good behaviours are accepted

by the roles. The proposed trust models take into account role inheritance and hierarchy in the evaluation

of trustworthiness of the roles. In addition, we present a design of a trust-based cloud storage system which

shows how the trust models can be integrated into a system that uses cryptographic RBAC schemes.

1 INTRODUCTION

Controlling the access to data is an important issue in

data storage systems. A proper access control mech-

anism is needed depending on the context and the re-

quirement of the system. Many access control models

have been proposed over the years in the literature.

Role-based access control (RBAC) is a well-known

access control model which can help to simplify secu-

rity management especially in large-scale systems. In

RBAC, roles are used to associate users with permis-

sions on resources. Users are assigned roles and per-

missions are allocated to roles instead of individual

users; only users who have been granted membership

to roles can access the permissions associated with

the roles and hence can access the resources. Since

being ﬁrst formalised in 1990’s(Ferraiolo and Kuhn,

1992), RBAC has been widely used in many systems

to provide users with ﬂexible controls over the access

to their data. The RBAC model was extended and

updated in 1996(Sandhu et al., 1996), and the RBAC

standard was proposed in 2000(Sandhu et al., 2000).

In traditional systems, access control policies are

usually speciﬁed and enforced by a central authority

who has administrative control over all the resources

in the system. With the rapid increase in the amount

of digital information that needs to be stored, cloud

storage has attracted much attention in recent years

because of its ability to deliver storage resources to

users on demand in a cost effective manner. In such

an environment, there may not exist a central author-

ity as the data may be stored in distributed data centres

which cannot be under the control of a single author-

ity. One approach to control the access to data in an

untrusted environment is to encrypt the data and give

the key to users who require access to the data.

Several cryptographic RBAC schemes have been

developed to allow data encryption in the context

of the RBAC model. A hierarchical cryptographic

access control scheme(Akl and Taylor, 1983) was

proposed in 1983. Because of the similarity in struc-

tures between hierarchical access control and RBAC,

a hierarchical cryptographic access control scheme

can be easily transformed into a cryptographic RBAC

scheme. The problem of access control for securely

outsourcing data using cryptographic techniques was

ﬁrst considered in (Miklau and Suciu, 2003). Some

other schemes were proposed afterwards, such as

in (Samarati and di Vimercati, 2010; di Vimercati

et al., 2010; Zhu et al., 2011). Recently, a new

Zhou L., Varadharajan V. and Hitchens M..

Trust-based Secure Cloud Data Storage with Cryptographic Role-based Access Control.

DOI: 10.5220/0004508600620073

In Proceedings of the 10th International Conference on Security and Cryptography (SECRYPT-2013), pages 62-73

ISBN: 978-989-8565-73-0

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

role-based encryption (RBE) scheme has been

proposed in (Zhou et al., 2011). In this scheme,

the user memberships are managed by individual

roles as opposed to a central administrator like in

other cryptographic RBAC schemes. These schemes

combine cryptographic techniques and access control

to protect the privacy of the data in an outsourced

environment where data can be encrypted in such a

way that only the users who are allowed by the access

policies can decrypt and view the data.

In some cases though the access control policies

may be speciﬁed by the cloud provider authority

itself in a centralised way, there could be multiple

authorities to enforce these access policies distributed

throughout the cloud system. Therefore there would

be a need to trust these authorities to correctly specify

the access control policies and enforce them properly.

In some cryptographic RBAC schemes, roles and

their users are managed by administrators who hold

the master secrets of the systems. All the administra-

tion tasks in these schemes are centralised. Therefore,

if one wants to know if a RBAC system is secure,

s/he only needs to determine the trustworthiness of

the administrator of the system.

However, in large-scale RBAC systems, it is

impractical to centralise the task of managing these

users and permissions, and their relationships with

the roles in a small team of security administrators.

The paper (Zhou et al., 2011) proposes a new crypto-

graphic RBAC scheme called Role-based Encryption

(RBE) in which the user management can be decen-

tralised to individual roles; that is, the administrators

only manage the roles and the relationship among

them while the role managers have the ﬂexibility in

specifying the user memberships themselves. In this

paper, we consider trust models for cloud storage

systems that are using cryptographic RBAC schemes

like RBE, where each individual role manager can

manage their user memberships without the need of

involving the administrators. We believe this case is

more general and can be used in large-scale RBAC

systems. In such systems, the trust on the individual

roles needs to be considered instead of the trust on

the administrators.

There have been several trust models

(Chakraborty and Ray, 2006; Toahchoodee et al.,

2009) for RBAC proposed in the literature. These

trust model considered the trust on users to assist

the decision making about whether or not to grant

permissions to the users. In a cloud storage system

using cryptographic RBAC schemes, it would also

be helpful if a user could determine whether or not

a role in the system is trusted before joining it. This

would be useful especially in systems where there

is a cost for users to join a role, for example, users

need to pay the subscription fee for joining roles.

When a user evaluates the trust value of a role, s/he

will only proceed with joining the role if the trust

value of the role is above a certain trust threshold

(this threshold being set by the users, and being

different for different applications and context). In

a system where owners are allowed to choose the

roles to assign their data, from the users’ perspective,

malicious owners can also cause negative behaviours

of roles by assigning bad resources (e.g. virus,

malware) to roles. Therefore, roles will also need to

consider the trust of the data owners so that only data

from well-behaved owners will be accepted.

Contributions of this Paper. The main contributions

of this paper are trust models for securing data stor-

age in cloud storage systems that are using crypto-

graphic RBAC schemes. Though much work exists

on trust models in RBAC, none of this work consid-

ers the trust on the RBAC system itself. The pro-

posed trust models address the missing aspect of trust

in cryptographic RBAC schemes to improve the deci-

sion making for entities (users and role managers) in

the cloud system. This paper proposes trust models

to assist (i) the users to evaluate the trust on the roles

in a RBAC system and use this trust evaluation to de-

cide whether to join a particular role or not, and (ii)

the role managers to evaluate the trust on the owners

in the RBAC system and use this trust in the decision

to accept data from an owner. We refer to these trust

models as User RBAC and Role RBAC trust models

respectively. These trust models can not only prevent

users from joining roles which have bad historical be-

haviour in terms of sharing poor quality resources or

misleading users on the content of resources, but also

assist the roles to identify the malicious owners who

have caused bad impact on the roles’ trustworthiness.

Our users’ trust model takes into account the effect of

role inheritance in RBAC systems on the trust evalua-

tion. If a role A inherits all the permissions that a role

B has, then we say role A is a ancestor role of role

B, and role B is a descendent role of role A . We also

present the architecture of a trust-based cloud storage

system which integrates the trust models in a crypto-

graphic RBAC system. Furthermore, we describe the

relevance of the trust models by considering practi-

cal application scenarios and then illustrate how the

trust evaluations can be used to enhance the quality

of secure decision making by users and roles of cloud

storage service.

The paper is organised as follows. Section 2 re-

views relevant preliminary knowledge that is needed

for the design of our trust models. Section 3 describes

the trust issues in a cryptographic RBAC system and

Trust-basedSecureCloudDataStoragewithCryptographicRole-basedAccessControl

discusses the trust requirements for users and roles.

We give the formal User and Role RBAC trust mod-

els in Section 4. The architecture of our secure cloud

storage system is presented in Section 5. In Section

6, we illustrate how our trust models can be used in a

cloud service application to enhance the quality of se-

curity decision making. Section 7 discusses relevant

related works and compares them with our proposed

trust models. Section 8 concludes the paper.

2 PRELIMINARIES

2.1 Experience-based Trust

Trust has played a foundational role in security for a

long period of time. It is clear that two entities may

not trust each other on the identity alone. There are a

range of other attributes and credentials such as dif-

ferent types of privileges, the state of the platform

being used as well as reputations, recommendations

and histories that come into play in decision making.

An experience-based trust model is one trust manage-

ment system which enables the trust decisions to be

made based on the historical behaviour of an entity.

Such a system allows an entity to rate the transac-

tions with other entities, and the trustworthiness of

an entity is determined using the collection of ratings

of the transactions that other entities have had with

this entity. In most experience based trust systems,

one entity derives the trustworthiness of another en-

tity from both experience of the former with the latter

and the feedback on transactions provided by other

entities which have had interactions with target entity

in the past. An entity is able to evaluate its trust in an-

other entity and the former can make a decision as to

whether to not to continue its transaction with the lat-

ter, based on whether the trust value exceeds a certain

threshold; this threshold is dependent on the context

of the application at hand.

2.2 Bayesian Trust Model

Many approaches have been proposed that use prob-

abilistic models to evaluate trust based on evidence

which contains the number of “positive” and “nega-

tive” transactions in which a given entity have been

involved. Perhaps the most common probabilistic

model is the one based on Bayesian trust (Mui et al.,

2001; Mui et al., 2002; Jøsang and Ismail, 2002) us-

ing the beta probability distribution function. The

beta family of distributions is a collection of continu-

ous probability density functions deﬁned over the in-

terval [0, 1]. Suppose a beta distribution used for a

parameter θ is deﬁned as

P(θ) =

Γ(α+ β)

Γ(α)Γ(β)

α−1

(1− θ)

β−1

where α and β are two parameters controlling the dis-

tribution of the parameter θ, and 0 ≤ θ ≤ 1, α >

0, β > 0. Assume X = {x

, . . . , x

} is the collection

of the feedbacks from the past n transactions, and

X has r “positive” feedbacks and s “negative” feed-

backs. Then the likelihood function can be deﬁned

P(X|θ) =

∏

i=1

P(x

|θ) = θ

(1− θ)

The posterior distribution P(θ|X) is propositional

to the multiplication of the prior P(θ) and the likeli-

hood function P(X|θ), and we then have

P(θ|X) =

P(X|θ)P(θ)

P(X)

Γ(r+ α+ s+ β)

Γ(r+ α)Γ(s+ β)

r+s−1

(1− θ)

s+β−1

Now let x

i+1

be the possible feedback of the next

transaction. The probability that x

i+1

is a “positive”

feedback given the transaction history X can be rep-

resented as

P(x

i+1

|X) =

dθ P(x

i+1

|θ)P(θ|X)

dθ θP(θ|X)

= E(θ|X)

Then we write the probability that the next trans-

action will be a “good” one as follows:

E(r, s) = P(x

i+1

|X) =

r+ α

r+ α+ s+ β

(1)

Using Equation 1, one entity can derive the proba-

bility that the next transaction with another entity will

be positive from the transaction history of the other

entity. Most Bayesian trust systems assume that the

parameters α = β = 1, such as in (Jøsang and Ismail,

2002). Some other approaches allow the parameters α

and β to be chosen depending on the system context.

3 TRUST ISSUES IN USING

CRYPTOGRAPHIC RBAC

SCHEMES IN SECURE CLOUD

STORAGE

Cryptographic RBAC schemes integrate crypto-

graphic techniques with RBAC models to secure the

SECRYPT2013-InternationalConferenceonSecurityandCryptography

data storage. They inherit the features and concepts

from RBAC models, and also have additional compo-

nents that are speciﬁc to data storage systems. In the

standard RBAC model, permissions are assigned to

roles by the administrator of the system. However, in

a system using cryptographic RBAC schemes, “per-

missions” are the data encrypted to roles, and the se-

curity policies are speciﬁed to control the users’ ac-

cess to data. Because data are usually not owned by

a single party, cryptographic RBAC systems assume

that data can be encrypted to a role by whoever owns

the data as opposed to the administrator in the stan-

dard RBAC system. In this paper, we address trust is-

sues for cryptographic RBAC systems. Therefore we

adopt the above described concepts for cryptographic

RBAC systems in our trust models.

Using cryptographic RBAC schemes in cloud

storage systems, a data owner can encrypt the data

to a role, and only the users who have been granted

membership of that role or an ancestor role of that

role can decrypt the data. In this paper, we assume

that the data owners and users reside outside this role

system infrastructure (where the roles are being ad-

ministered). Hence the issues to consider are how the

users can decide whether or not to trust the roles (role

managers) in the system and how the roles can decide

whether to trust the data owners in the system and

how much to trust them. Users consider their trust in

roles in order to ensure that joining roles guarantee ac-

cess to data assigned to these roles, and roles consider

their trust in data owners to ensure that data owners

who have assigned malicious data to the roles will not

be allowed to assign data to the roles any more. In

this section, we discuss the trust issues that need to be

considered by the users and roles of a cryptographic

RBAC system.

3.1 Users’ Trust on Roles in RBAC

Systems

Some cryptographic RBAC schemes assume that

user-role assignment is managed by administrators of

the systems where the administrators check the quali-

ﬁcation of users and grants role membership to them.

In these schemes, users trust all the roles at the same

level as they are all managed by the same administra-

tors. The roles are trusted as long as the administra-

tors are trusted.

In some other cryptographic RBAC schemes,

users-role assignment is decentralised to individual

role managers to allow more ﬂexibility in user man-

agement especially in large-scale systems. In systems

using these schemes, assume that users join a role

based on subscription for accessing the data assigned

to that role. It is clear that users need to choose a

trusted role when subscribing.

If the data that a user wants to access is encrypted

to one role only, the user considers the trustworthiness

of that role in deciding whether or not to join that role.

When the same data is encrypted to multiple roles,

users will need to evaluate the trustworthiness of these

roles to choose the most reliable role to join. From

the user’ perspective, a trusted role should meet the

following requirements.

• Requirement 1: The role manager should grant

membership to the users who are qualiﬁed for that

role.

In order to access data, a user needs to join a role

to which the data is encrypted. When the user re-

quests to join the role, the role (manager) should

give access (grant the membership) to the user if

the user qualiﬁes for that role, e.g. the user has

paid for the subscription fee. Refusing to do so

will be considered as bad behaviour of the role.

• Requirement 2: The data that a role claims to

have should have been encrypted properly to that

role.

When users want to access data, they will need to

know what data has been encrypted to which role

so that they can choose a particular role to join.

The list of the data is provided by roles. How-

ever, a user may ﬁnd that s/he cannot locate or de-

crypt the data even after s/he has joined that spe-

ciﬁc role. This may happen if the data was not

encrypted properly to that role by the owner, or

the role claims to possess data that has not been

encrypted to the role. Each role should take the

responsibility of providing a valid and up-to-date

list of the data that is in its possession.

• Requirement 3: The data that the descendantroles

of the role claim to have should have been en-

crypted properly to the descendant roles.

Since a role can inherit permissions from its de-

scendant roles, a user who has joined a role should

be able to access the data that is encrypted to any

of its descendant roles. Each role is liable for the

validity of the data that its descendant roles claim

to have, as it is considered to be part of the data

that this role has.

3.2 Roles’ Trust on Owners in RBAC

Systems

In cryptographic RBAC systems, owners can en-

crypt their data to any role. Obviously, roles do not

Trust-basedSecureCloudDataStoragewithCryptographicRole-basedAccessControl

want owners to encrypt malicious data (e.g. virus,

malware) to them. Therefore, roles need to decide

whether or not to accept data that owners want to as-

sign to them. Having malicious data assigned to a

role may result in a low trust value of the role be-

cause users who have joined the role will place neg-

ative trust records against the role if they detect that

the data they get from the role is malicious. In the

case where roles are proﬁting from users’ subscrip-

tions, low trust values in roles implies the risk of los-

ing business.

To help roles detect malicious owners, and hence

avoid accepting data from them, another trust model

is required to assist roles in evaluating the trustworthi-

ness of owners. Each time an owner wants to assign

data to a role, the role will use the trust model to deter-

mine whether the data is coming from a trusted owner

or not. From a role’s perspective, a trusted owner

should meet the following requirements.

• Requirement 1: The data from the owner should

be the same as its description.

When owners encrypt and assign data to a role,

the role may not be able to verify each individ-

ual record from the owners. When a user who has

joined a role ﬁnds that the data s/he has accessed

is not the data it claims to be or contains mali-

cious records, the user will complain to the role

about the data, and the role should place a nega-

tive trust record against the owner who owns that

data. Then next time this owner wishes to assign

another data to the role, this trust record will be

used by the role in making the decision whether

or not to accept the data.

• Requirement 2: The owner should not be consid-

ered as untrusted by any role in the system, if the

owner has assigned data to more than one role

before.

An owner may have had interactions with more

than one role in the system. A trusted owner is

supposed to act consistently in the interaction with

different roles. An owner may still be considered

as untrusted even though s/he has good interaction

histories with a small portion of roles in the sys-

tem. Thereforea trusted ownershould try to main-

tain good interaction histories with all the roles in

the system. When a role is interacting with an

owner with which it has not interacted before, the

trust opinions from other roles can assist this role

to determine the trustworthiness of the owner.

4 TRUST MODELS FOR

CRYPTOGRAPHIC RBAC

SYSTEMS

In this section, we consider the trust models for a

cryptographic RBAC system. There are three types

of entities in our trust models, Owner, User and Role.

Our trust models can assist a User to decide whether

a Role to interact with is trusted, and assist a Role in

determining the trustworthiness of an Owner. We ﬁrst

deﬁne these three entities as follows.

Owner: the entity who owns the data and stores it in

an encrypted form for particular roles in the cloud.

User: the entity who wishes to access the data stored

in the cloud.

Role: the entity that associates users with the access

to owners’ data, and each role manages the user

membership of itself. Here when we say that users

are managed by a role, we refer to the managers

of the role who determine the user set of that role.

In our trust models, we assume that all the feed-

back and recommendations provided are honest. In

other words, we assume that the trust system has the

ability to verify the submitted feedback and recom-

mendations, and only the valid ones will be consid-

ered in the trust evaluations.

4.1 Users’ Trust on Roles

In this subsection, we consider the trust model about

user’s trust on roles in a RBAC system.

Deﬁnition 1 (Interaction). From a user’s perspec-

tive, an interaction is a transaction in which a user

accesses data that is encrypted to a role to which the

user belongs.

A successful interaction is an interaction where a

user has successfully accessed the data. An unsuc-

cessful interaction is an interaction where a user failed

in accessing the data to which s/he should have legit-

imate access. Next we deﬁne two types of unsuccess-

ful interactions.

User Management Failure: User management fail-

ure is an unsuccessful interaction caused by incor-

rect user membership management of a role; that

is, the role did not grant the membership to the

user even when the user qualiﬁes for the role.

Permission Management Failure: Permission man-

agement failure is an unsuccessful interaction

where the data encrypted to a role is invalid, or the

data is not encrypted to the role. In other words,

the owner of the data did not encrypt the data to

SECRYPT2013-InternationalConferenceonSecurityandCryptography

the role in question or encrypted an invalid data to

the role.

Deﬁnition 2 (Trust Vector). We deﬁne a trust vector

to represent the behaviour history of a role as follows:

v = (r, s

, s

)

In the trust vector, r is the value related to successful

interactions that users have had with a given role, s

is the value related to User Management Failure of

the role, and s

is the value related to the Permission

Management Failure.

Using the function E in Equation 1, we deﬁne the

trust function T(v) that represents the trust value de-

rived from the trust vector v as

T (v) = E(r, s

+ s

)

Deﬁnition 3 (Interaction History). We assume that

there exists a central repository in the system that col-

lects and stores the ratings from users on the inter-

actions between users and roles. We deﬁne the trust

record history derived from the ratings of the role R

from n users as

Hist

(R) = {H

, H

, ··· , H

}

Each entry H

in Hist(R) is deﬁned as a pair of

parameters, H

= hU

, v

i,R

i, where v

i,R

= (r, s

, s

) is

a trust vector that represents the trust record of inter-

actions that the user U

has had with the role R. r is

the number of U

’s positive feedbacks on the interac-

tions with R, s

is the number of negative feedbacks

on the interactions with R due to User Management

Failure, and s

is the number of negative feedbacks

on the interactions with R due to Permission Manage-

ment Failure.

In a cryptographic RBAC system, a user who be-

longs to a role not only has access to the data of the

role, but also has access to the data of descendent

roles. Therefore, an invalid resource from a descen-

dent role may also cause an unsuccessful interaction.

Since a role knows whether a resource comes from

its descendent roles, we assume that users give feed-

back to the roles to whom the resources are directly

assigned; that is, if a user detects an invalid resource

from a descendent role, s/he will update the feedback

for the descendent role directly instead of the role s/he

belongs to.

As discussed in Subsection 3.1, from the users’

perspective, the trustworthiness of a role is affected

by the interaction history of the role and its descen-

dant roles. Therefore users need to consider the fol-

lowing types of trust classes when evaluating the trust

on roles.

Individual Trust. Individual trust is a belief that is

derived directly from interaction history of the role R.

When a user U

wishes to evaluate the trust value

of a role R, the user ﬁrst obtains the interaction his-

tory Hist

(R) of the role from the central repository.

Assume that w

is the weight that the user U

assigns

to the feedbacks from other users. Then the individual

trust value of the role R can be computed as follows,

(R)

= T (v

k,R

where v

k,R

= v

k,R

+ w

∑

i=1,i6=k

i,R

where the trust vector v

k,R

is a combination of all trust

vectors in Hist

(R) considering the weighting for the

trust vectors from other users.

Inheritance Trust. Inheritance trust is a belief that is

derived from the interaction history of the descendant

roles of a given role.

Assume a role R has m immediate descendant

roles {R

, ··· , R

}, and a weight vector w

is de-

ﬁned as (w

, 0, w

) where w

∈ [0, 1] is the weight

assigned to inheritance relationship between R and

. The second element is set to zero because User

Management Failure is not considered in inheritance

trust as user management of descendant roles will not

cause any unsuccessful interaction for this role. The

inheritance trust of roles in a hierarchy is computed

as follows:

(R)

= T (v

k,R

where v

k,R

∑

i=1

[(v

k,R

+ v

k,R

), w

]

In the above equation, [v, w] := v

w is the usual dot

product on Z

Combination Trust. To compute the trust value of a

role, , wedeﬁne a combinationtrust function for a role

R as T

(R) to combine the above described two type

of trust together. Assume that w ∈ [0, 1] is the weight

of the inheritance trust. The trust value is computed

(R) = (1− w) · T

(R)

+ w· T

(R)

4.2 Example of Users’ Trust on Roles

Now we use an constructed example to show how the

users’ trust on a role is affected by feedback for dif-

ferent roles in a RBAC system. In this example, we

consider all the bad feedback as Permission Manage-

ment Failure, as our intention is to show how the role

hierarchy affects the trust value of roles. Consider the

role hierarchy example shown in Figure 1.

In Figure 1, the role R

inherits from role R

and

role R

, and the role R

inherits from R

and R

. We

set the weight between every two roles and the weight

Trust-basedSecureCloudDataStoragewithCryptographicRole-basedAccessControl

R3 R4

Figure 1: Hierarchical RBAC.

of other owners’ feedback to 1; that is, the weight

vector for each role R

where k ∈ [1, 5] is deﬁned as

= (1, 0, 1), ∀ i ∈ [1, 5], i 6= k, and w

= (1, 1, 1).

When a user wants to access a resource that has been

assigned to the role R

, s/he will need to evaluate

the trust value of R

to decide whether R

is reli-

able to join. In Figure 2, we show the trust values of

when only different individual roles in the RBAC

system have feedback. For example, the curve for

, GFP = 75% shows the trust values of R

when

only R

in the RBAC system has feedback, and 75%

of the feedback is positive.

When the good feedback percentage is 75%, the

trust value for R

goes up with the increasing number

of feedbacks that R

and R

have. This trend implies

that the more resources a role has, the more impact the

good feedback percentage has on the trust value of the

role. Note that the feedback for R

does not affect the

trust value of R

. This is because an untrusted R

will

not cause an unsuccessful interaction of R

. When the

feedback is only given for R

, the increase in the trust

value is the fastest. This is because the individual trust

of the role has more weight than the inheritance trust

by our assumption. It is clear that the increase in the

trust value of R

is slower when the feedback is for R

only, because inheritance trust has less weight in this

example.

When the good feedback percentage is 25%, the

trust value for R

goes down with the increasing num-

ber of feedbacks that R

and R

have. Similarly, this

trend implies that the more resources a role has, the

more impact the good feedback percentage has on the

trust value of the role. The feedback for R

does not

affect the trust value of R

either. When feedback is

only given for R

, the decrease in the trust value is the

fastest. This is because the individual trust of the role

has more weight than the inheritance trust by our as-

sumption. Therefore the decrease in the trust value of

is slower when the feedback is for R

only.

From Figure 2, we see that the feedbacks for dif-

ferent roles in the system have different impact on the

trust value of R

. Firstly, the feedback for ancestor

roles does not affect the trust of the role. Secondly,

the more resources that have been assigned to a role,

the more impact the feedback for the role will have

on its ancestor roles as well as itself. These results

show that our users’ trust model is useful in assisting

users to determine properly the trust of roles in RBAC

systems.

4.3 Roles’ Trust on Owners

In the case when any owner can choose roles to en-

crypt their resources to, assigning malicious resources

or invalid resources to a role may cause the Permis-

sion Management Failure of the role. Therefore, it

would be useful to have a trust model to assist roles

in determining the trustworthiness of an owner, and

hence decide whether or not to accept the resources

from the owner.

As discussed in Subsection 3.2, the trust require-

ment on owners is simpler when compared with the

users’ trust on roles. When comparing these two types

of trust, we can see that there are some important dif-

ferences. The trust on owners is not related to the

role hierarchy; that is, the role hierarchy does not af-

fect the trust computation on owners. We note that a

general trust model can be used in this scenario. For

completeness purposes, we also give the deﬁnition of

the trust model for the roles’ trust on owners in this

subsection.

Deﬁnition 4 (Interaction). From a role’s perspec-

tive, an interaction with an owner is a transaction in

which an owner assigned a resource to that role, and

that the role has accepted the resource.

Deﬁnition 5 (Trust Vector). We deﬁne a trust vector

to represent the behaviour history of an owner as fol-

lows:

v = (h, s)

where h is the value related to resources owned by the

owner, s is the value related to malicious or invalid

resources owned by the owner.

Using the function E in Equation 1, we deﬁne the

trust function T(v) that represents the trust value de-

rived from the trust vector v as

T (v) = E(h − s, s)

Deﬁnition 6 (Interaction History). We assume that

there exists a central repository in the system that col-

lects and stores the behaviour histories provided by

roles to which the owner has assigned the resources.

We deﬁne the trust record history provided by a set R

of n roles as

Hist

(O) = {H

, H

, ··· , H

}

SECRYPT2013-InternationalConferenceonSecurityandCryptography

0 10 20 30 40 50 60 70 80 90 100

0.45

0.5

0.55

0.6

0.65

0.7

Number of Feedbacks

Trust Values

Trust Values of Roles, Good Feedback Percentage 75%, w = 0.3

0 10 20 30 40 50 60 70 80 90 100

0.3

0.35

0.4

0.45

0.5

0.55

Number of Feedbacks

Trust Values

Trust Values of Roles, Good Feedback Percentage 25%, w = 0.3

Figure 2: Trust Values on R

for Users from Feedback on Different Roles.

Each entry H

in Hist(O) is deﬁned as a pair

of parameters, H

= hR

, v

i,O

i where v

i,O

= (h, s) is

a trust vector that represents the trust record of the

owner O on the resources that s/he has assigned to the

role R

. h is the total number of O’s resources that

has been assigned to R

, and s is the number of bad

resources assigned by O.

We assume that an owner O has a resource and

wants to assign it to a role R

. When this resource is

assigned to the role R

, R

updates the trust record

of the owner by increasing the value h in the trust

vector H

of O by 1. Now assume that a user has

found the resource to be invalid, and then s/he reports

to the role of this resource. If the role has conﬁrmed

that the user’s complaint is true after verifying the re-

source, R

will ﬁnd out that it is O who uploaded this

resource, and R

will increase the value s in trust vec-

tors H

for this owner by 1.

A user that belongs to a role has the permission to

access resources of the descendant roles of the role.

When the user reports a bad resource from its descen-

dant role, this role may not be able to identify the

owner of the resource as the resource is not assigned

to this role directly. Hence the role cannot update

the trust records of the owner. In this case, the role

can notify all its descendant roles about this bad re-

source, and the role to which the resource is assigned

to will update the trust record of the owner who owns

resource.

Assume that w is the weight that the role R

as-

signs to the feedback from other roles. Taking as in-

put the interaction history of an owner, the trust value

of the owner can be computed as follows:

(O) = T (v

k,O

), v

k,O

= v

k,O

+ w·

∑

i=1,i6=k

i,O

This trust value is evaluated based on a combina-

tion of all trust records in Hist

(O) considering the

weighting for the trust records from other roles.

5 ARCHITECTURE

In this section, we present the design of a secure

cloud storage system by combining the trust models

for RBAC proposed in Section 4 with a cryptographic

RBAC system. This architecture provides a practi-

cal solution for building a reliable and trusted RBAC

system while retaining the use of cryptographic tech-

niques. We have implemented a prototype of this ar-

chitecture and have been conducting a range of exper-

iments.

5.1 System Overview

Consider the system architecture shown in Figure 3.

Each solid line in the ﬁgure shows the communica-

tion channel set by the system between two compo-

nents joined together by the line, and the arrows in-

dicate the direction in which the information ﬂows.

Since our trust models are based on cryptographic

RBAC schemes, our system contains all the entities

that a cryptographic RBAC scheme has, including an

administrator, roles, users and owners. The admin-

istrator is the certiﬁcate authority of the RBAC sys-

tem, and it generates the system parameters and is-

sues all the necessary credentials. In addition, the

administrator manages the role hierarchy of the sys-

tem. To put a role into the role hierarchy, the admin-

istrator needs to compute the parameters for that role.

These parameters represent the position of the role in

the role hierarchy. They are stored in the cloud, and

are available publicly. Roles are the entities that as-

sociate users and owners together. Each role has its

own role parameters which deﬁne the user member-

ship. These role parameters are stored in the cloud,

and a role needs to update them in the cloud when up-

dating the user membership of the role. Owners are

the parties who possess the data and want to store the

Trust-basedSecureCloudDataStoragewithCryptographicRole-basedAccessControl

Owner Behaviour

Auditor

Role Behaviour

Auditor

Interaction History Central Repository

Users

Owner Behaviour

Controller

Trust Decision

Engine

Cloud

Administrator

Roles

Trust Management

System

Owner

Figure 3: Architecture.

encrypted data in the cloud for other users to access,

and they specify the roles who can access the data. In

the RBAC model, they are the parties who manage the

relationship between permissions and roles. Users are

the parties who wish to acquire certain data from the

cloud. When a user wishes to access stored data in the

cloud, s/he ﬁrst sends the request to the cloud, and de-

crypts the data upon receiving the response from the

cloud.

In addition to these four entities in a basic cryp-

tographic RBAC scheme, our trust enhanced crypto-

graphic RBAC system by integrating an extra trust

management system, which consists of ﬁve compo-

nents. Next, we describe the details of these compo-

nents.

Central Repository. In our trust models, all the inter-

action histories and trust records related to roles and

users are stored in a central repository. The central

repository is used to keep the records of all these in-

teraction histories and trust records which are used by

the Trust Decision Engine (described below) in eval-

uating the trust value of roles and owners. Any entity

that is residing outside the trust management system

is not able to access the central repository.

Role Behaviour Auditor. In order to protect the in-

tegrity of the feedback on roles, a role behaviour au-

ditor collects the feedback for roles from users. The

role behaviour auditor needs to ensure that a user who

uploads feedback against a role has been granted the

membership of the role or an ancestor role of that role.

All the valid feedback will be forwarded to the central

repository, and invalid feedback will be discarded.

Owner Behaviour Auditor. An owner behaviour au-

ditor is an entity to collect the feedback on owners’

behaviour. However, different to the role behaviour

auditor, the owner behaviour auditor listens for feed-

back on two channels. One is from the roles who may

report the invalid data, and another is from the owner

behaviour controller which reports the ownership of

the stored data in the cloud. This auditor will deter-

mine whether an owner has uploaded any malicious

or invalid data to the cloud, and can update the central

repository.

Owner Behaviour Controller. Owner behaviour con-

troller acts as a proxy server between owners and the

cloud. It controls and forwards the owners’ encrypted

data to the cloud. The controller can decide whether

to store data in the cloud based on the decision from

the role to which the data is assigned. The controller

will inform the owner behaviour auditor the informa-

tion about which owner the uploaded data belongs to.

Trust Decision Engine. The trust decision engine is

the entity which evaluates the trust of the roles for

users and the trust of the owners for roles. The trust

decision engine takes as input the interaction histories

or trust records stored in the central repository, and

outputs the trust value of a particular role or owner.

5.2 System Workﬂow

All the entities in the system are connected through

different communication channels which are labelled

with numbers in Figure 3. We explain how the sys-

tem works by describing the information ﬂow through

these channels.

First, the administrator initialises the system and

speciﬁes the role hierarchy of the system. The gen-

erated system parameters are uploaded to the cloud

via channel 1. Roles grant the membership to users,

and upload role parameters to the cloud via channel

2. Users download and decrypt data from the cloud

via channel 3. When an owner wants to encrypt and

store data in the cloud to a particular role, s/he ﬁrst

encrypts the data and sends a request to the owner be-

haviour controller via channel 6. Then the owner be-

haviour controller notiﬁes the role via channel 11 and

forwards the request to the cloud through channel 7 if

the role agrees to accept the data from this owner. The

cloud then communicates with the owner as in a nor-

mal cryptographic RBAC scheme. The controller also

sends the owner behaviour auditor the information

about the owner’s identity and the resource’s identity

via channel 8.

When a user wants to access a resource in the

RBAC system, the system ﬁrst returns a list of roles

who claim to have this resource. Then the user re-

quests the trust evaluationon these roles from the trust

management system. The trust value of the roles will

be returned to the user through the channel 13. The

the user may choose a role who has the highest trust

value to send the join request. When a user has found

SECRYPT2013-InternationalConferenceonSecurityandCryptography

that the data s/he has accessed from the role is ma-

licious or invalid, s/he then provides a feedback on

the role to whom the resource is encrypted to the role

behaviour auditor through channel 4. Once the role

behaviour auditor veriﬁes that the feedback is from

an authorised user, it will forward the feedback to the

central repository.

When a negative feedback of a role has been

raised by a user because of an invalid resource, the

role will send the identity of the resource to the owner

behaviour auditor via channel 10 if it believes that the

resource was invalid when the owner uploaded the re-

source. The auditor then updates the trust records of

the owner of this resource to the central repository via

channel 9. When an owner wants to assign a resource

to a role, the role can ask the trust management sys-

tem about the trust evaluation for a owner, and the

trust value will be returned by the trust decision en-

gine through channel 14. Upon receiving the trust

values for the owner from the trust decision engine,

the role can inform the owner behaviour controller via

channel 11 whether to accept the data. Moreover, this

trust evaluation process can be made automatically

by connecting owner behaviour controller to the trust

decision engine directly. Roles can pre-determine a

trust threshold for accepting data from owners. Every

time an owner wants to upload a resource, the owner

behaviour controller can check the trust value of the

owner from the trust decision engine directly, and de-

cide whether to accept the resource by comparing the

trust value with the role’s threshold.

6 APPLICATION SCENARIO

In this section, we describe a digital library system

which uses our proposed trust models to illustrate how

the trust models can assist the security decision mak-

ing in this system. The digital library system uses an

external public cloud to store all the digital format re-

sources such as books, papers, theses, and other types

of publications. There are many distributors who use

the platform provided by the digital library system to

share digital resources. Each distributor can get the

authorisations for sharing the digital resources from

the publishers directly. A party who subscribes to

a distributor can access all the resources of the dis-

tributor. Assume that the distributors have two types

of subscription licenses; personal licenses that allow

only the subscribed user to access the resources, and

business licenses that allow another distributor to re-

sell the resources to other users or distributors.

Now let us consider an example distributors net-

work for this digital library system. The hierarchi-

M1 M2

B1 Business 1

B2 Business 2

M1 Marketing 1

M2 Marketing 2

E Economics

AD Advertising

CS Customer Service

PR Public Relations

C Commerce

PRCS

Figure 4: Application of Digital Library System.

cal relationship of the distributors is shown in Fig-

ure 4. In this system, distributors choose the re-

sources to share by their categories. The distribu-

tors AD,CS, PR,C, M

get the authorisations for sell-

ing digital resources in the categories Advertising,

Customer Service, Public Relations, Commerce and

Marketing respectively from the publishers. Distribu-

tors M

and E sell a wider ranger of resources which

cover all the categories in Marketing and Economics

respectively, and these two distributors get authorisa-

tions from the distributors of sub-categories instead

of the publishers directly. Note that the categories of

resources sold by M

and M

are overlap. The differ-

ence is the channels they get the resources from: M

from publishers, and M

from sub-distributors. Sim-

ilarly, distributors B

and B

get authorisations from

, E and M

, E respectively, and their resources both

cover the categories Business.

To use cryptographic RBAC schemes to protect

the resources so that only the authorised users can ac-

cess, the administrator of the digital library system

ﬁrst sets up the system parameters based on the rela-

tionships of the distributors. Then the publishers can

encrypt their resources to the distributors whom they

authorised to sell the resources. Here we consider the

distributors as roles in the RBAC, and publishers as

owners of the resources. When a user subscribes to

a distributor, the distributor simply adds the user to

the role. Then the user can use the key given by the

system administrator to decrypt the resources of the

role. Because the cryptographic RBAC schemes sup-

port role hierarchy, in this example, users who sub-

scribed to the role M

can also access the resources of

the role AD, CS and PR, and users subscribed to B

can access the resources of all the roles M

, E,C.

First let us consider how the trust model can assist

the users. Assume that the distributor M

also gets

some resources, which the distributors AD,CS, PR do

not have directly from the publishers. To save the

cost of storing resources in the cloud, M

chooses to

reprint some resources in a lower quality to reduce

the ﬁle size. Users subscribed to M

may give neg-

ative feedbacks on M

because they have difﬁculties

Trust-basedSecureCloudDataStoragewithCryptographicRole-basedAccessControl

in reading some of the resources. Later on, when a

user want to access marketing resources, s/he evalu-

ates the trust of M

and M

, and the trust model will

output a higher trust value for M

than for M

because

of the negative feedbacks of M

. Then the user will

know the quality of resources from M

is better than

those from M

. However, the distributors AD,CS, PR

will not be affected because the poor quality resources

are not coming from them. When a user wants to sub-

scribe to a distributor for Business, B

will have lower

trust value than B

as resource the user would get from

may come from M

Now let us look at the trust model for roles’ trust

on owners. Assume that publishers want to promote

their digital resources, and they actively assign their

resources to distributors. The resources that have

come from some publishers may be of poor quality

or alternatively some resources are not what the pub-

lishers claim to be. The distributors may not be able to

verify each individual resource due to the lack of ex-

pertise in certain areas. When users complain about a

bad resource, the role can give a negative feedback on

the publisher who owns the resource, after conﬁrm-

ing that the users’ complaints is valid. The feedback

of the publisher can be accessed by all the distributors

so they can avoid using this publisher in the future.

7 RELATED WORKS

There have been some related works which have

addressed only trust on users in RBAC systems.

(Chakraborty and Ray, 2006) proposed a trust model

for RBAC system which considers users’ trust by as-

signing trust levels to users. These trust levels are

based on a number of factors such as user credentials,

user behaviour history and recommendations from

other users. Trust levels are then mapped to roles. An-

other trust model for RBAC was proposed in (Takabi

et al., 2007) to assist roles with the decision of user-

role assignment based on a wide range of criteria of

users, including behaviour history and reputation. In

(Feng et al., 2008), a trust model for RBAC was in-

troduced which evaluates the trust in the users based

on user behaviours and context, in a context-aware

access control model. Another trust model was dis-

cussed in (Toahchoodee et al., 2009) which also uses

trust level to determine the access privileges of users.

All these trust models only consider the trust on users

in a RBAC system. None of these works address the

users’ trust on roles in the RBAC system. The trust

for roles is critical in cloud storage systems which

has been addressed in this paper. As an extension of

the users’ RBAC trust model, our trust models have

also addressed the roles’s trust on owners. Another

difference between our model and the previously pro-

posed ones is that our trust models work in RBAC sys-

tems which use cryptographic RBAC schemes. That

is, our models take into account cryptographic oper-

ations and the access privileges to decrypt the data

stored in the cloud, which none of the previous works

address.

8 CONCLUSIONS AND FUTURE

WORK

In this paper, we have addressed trust issues in cryp-

tographic role-based access control systems for secur-

ing data storage in a cloud environment. We have pro-

posed trust models for users and roles in RBAC sys-

tems which are using cryptographic RBAC schemes

to secure stored data. These trust models assist the

users and roles to determine the trustworthiness of in-

dividualroles and ownersin the RBAC system respec-

tively. They allow the users to perform the trust eval-

uation to decide whether or not to access a resource

from a particular role. Our trust model takes into ac-

count role inheritance and hierarchy in the evaluation

of trustworthiness of roles. The models also enable

the roles to use the trust evaluation in their decision to

accept the resources from a particular owner. We have

given the design of an architecture of a trust-based

cloud storage system which has integrated these trust

models with the cryptographic RBAC schemes. We

have also described the application of the proposed

trust models by considering a practical scenario and

illustrating how the trust evaluations can be used to

reduce the risks and enhance the quality of security

decision making by users and roles of the cloud stor-

age service.

The proposed trust models used a centralised trust

management system to assist users and roles with

their trust evaluations. Though the users and roles in

the system still need to trust the centralised trust man-

agement components, we believe that this approach

has improved the cases where users and roles need

to trust each individual roles and data owners in the

system. We note that the auditing components in our

designed architecture need to collect all the provided

feedback. In large-scale systems, the load of these

auditing components could be high. One solution to

this issue is using decentralised auditing components

which will be considered in our future work. In ad-

dition, we only considered two types of feedbacks

in our trust models, positive and negative. However,

a user who has unsatisfactory experiences with roles

may want to provide varying levels of negative feed-

SECRYPT2013-InternationalConferenceonSecurityandCryptography

back. For example, the user may have retrieved a mal-

ware instead of valid data from a role and a poor qual-

ity data instead of a good quality one from the same

role. It is clear that the latter case is less harmful than

the former one, and the user may want to rate the role

less untrusted for the latter case. We will also consider

this issue in our future work.

REFERENCES

Akl, S. G. and Taylor, P. D. (1983). Cryptographic solution

to a problem of access control in a hierarchy. ACM

Trans. Comput. Syst., 1(3):239–248.

Chakraborty, S. and Ray, I. (2006). Trustbac - integrating

trust relationships into the rbac model for access con-

trol in open systems. In Proceedings of the eleventh

ACM symposium on Access control models and tech-

nologies, pages 49–58.

di Vimercati, S. D. C., Foresti, S., Jajodia, S., Paraboschi,

S., and Samarati, P. (2010). Encryption policies for

regulating access to outsourced data. ACM Trans.

Database Syst., 35(2).

Feng, F., Lin, C., Peng, D., and Li, J. (2008). A trust and

context based access control model for distributed sys-

tems. In HPCC, pages 629–634. IEEE.

Ferraiolo, D. F. and Kuhn, D. R. (1992). Role-based access

controls. In 15th National Computer Security Confer-

ence, volume 1-2, pages 554 – 563. National Institute

of Standards and Technology, National Computer Se-

curity Center.

Jøsang, A. and Ismail, R. (2002). The beta reputation sys-

tem. In Proceedings of the 15th Bled Conference on

Electronic Commerce.

Miklau, G. and Suciu, D. (2003). Controlling access to

published data using cryptography. In 29th Interna-

tional Conference on Very Large Data Bases, pages

898–909.

Mui, L., Mohtashemi, M., Ang, C., Szolovits, P., and Hal-

berstadt, A. (2001). Ratings in distributed systems: A

bayesian approach. In Workshop on Information Tech-

nologies and Systems.

Mui, L., Mohtashemi, M., and Halberstadt, A. (2002). A

computational model of trust and reputation for e-

businesses. In HICSS, page 188.

Samarati, P. and di Vimercati, S. D. C. (2010). Data protec-

tion in outsourcing scenarios: issues and directions. In

ASIACCS, pages 1–14. ACM.

Sandhu, R. S., Coyne, E. J., Feinstein, H. L., and Youman,

C. E. (1996). Role-based access control models. IEEE

Computer, 29(2):38–47.

Sandhu, R. S., Ferraiolo, D. F., and Kuhn, D. R. (2000).

The nist model for role-based access control: towards

a uniﬁed standard. In ACM Workshop on Role-Based

Access Control, RBAC00, pages 47–63.

Takabi, H., Amini, M., and Jalili, R. (2007). Trust-based

user-role assignment in role-based access control. In

AICCSA, pages 807–814. IEEE.

Toahchoodee, M., Abdunabi, R., Ray, I., , and Ray, I.

(2009). A trust-based access control model for perva-

sive computing applications. In DBSec, volume 5645

of Lecture Notes in Computer Science, pages 307–

314. Springer.

Zhou, L., Varadharajan, V., and Hitchens, M. (2011).

Enforcing role-based access control for secure data

storage in the cloud. The Computer Journal,

54(13):1675–1687.

Zhu, Y., Hu, H., Ahn, G.-J., Wang, H., and Wang, S.-

B. (2011). Provably secure role-based encryption

with revocation mechanism. J. Comput. Sci. Technol.,

26(4):697–710.

Trust-basedSecureCloudDataStoragewithCryptographicRole-basedAccessControl