Concurrent History-based Usage Control Policies

Fabio Martinelli, Ilaria Matteucci, Paolo Mori and Andrea Saracino

Istituto di Informatica e Telematica, Consiglio Nazionale delle Ricerche, Pisa, Italy

Keywords:

History-based Policy, Usage Control Policy, Data Sharing, Process Algebra.

Abstract:

The sharing of data and resources is one of the cornerstones of our society. However, this comes together with

several challenges regarding the increasing need of guaranteeing security and privacy during both the access

and the usage of such shared resources. Access control policies ﬁrst, and usage control policies secondly, have

been introduced to overcome issues related to the access and usage of resources. However, the introduction

of distributed and cloud systems to share data and resources enables the concurrent and shared access to the

same resources. Here we present an enhanced version of History-based Usage Control policies in which we

are able to manage concurrent access and usage of resources by several subjects, whose actions may inﬂuence

one another. Moreover, to ease the understanding of the proposed approach, we present a reference example

where a document is shared among a set of people having different roles in a company.

1 INTRODUCTION

Nowadays distributed, highly connected ICT and

Cloud systems are the main means to share re-

sources (data, storage space, computational power,

etc.) among organizations and/or individuals. This

leads to the necessity of designing and developing

proper security and privacy preserving infrastructures

that manage and regulate both the access and the

usage of such resources. In the recent years, sev-

eral technical approaches have been proposed in or-

der to cope with security and privacy issues in differ-

ent settings (Kelbert and Pretschner, 2015; Lazouski

et al., 2016). In particular, the Usage Control (UCON)

model, which has been deﬁned in (Park and Sandhu,

2004) to extend the capability of traditional access

control, proved to be an effective instrument in en-

forcing resource security (Neisse et al., 2013; La-

zouski et al., 2014). UCON enhances the expres-

siveness of standard access control by introducing the

continuous enforcement of security policies while an

access is in progress, being able to interrupt this ac-

cess as soon as the policy is not satisﬁed any more.

However, complex systems might have security re-

quirements for which the standard UCON model is

not expressive enough. To meet the security needs

of such complex systems, in (Martinelli et al., 2016)

the authors introduced History-based UCON policies,

which allow to deﬁne the allowed behaviour of a sys-

tem by combining Usage Control policies through

proper operators. History-based Usage Control poli-

cies are necessary in those scenarios where the right

of executing an action does not depend on that action

only, but also on (a proper subset of) all actions that

have been previously executed on the system.

Notwithstanding, still more work is required to

deal with issues of concurrency and shared resources.

In fact, in real scenarios a shared resource can be con-

currently used by several actors, working in different

ﬁelds and having different purposes. For example,

we can consider two individuals, respectively a doc-

tor and a patient, who are both related to a certain

medical examination document. Both of them have

the right of use this document according to a speciﬁc

(and different) History-based Usage Control policy.

This leads to the need of combining these policies in

a unique History-based Usage Control policy able to

describe all the behaviours allowed on the document.

Hence, in this paper we propose an enhancement to

the work in (Martinelli et al., 2016) by considering

concurrent History-based Usage Control policies, i.e.,

we add the possibility of combining policies through

a process algebra interleaving operator, named paral-

lel operator. This allows us to model concurrent be-

haviours and the possible interdependencies that may

exists among History-based Usage Control policies

through process algebra operators.

The rest of the paper is structured as follows: the

next section presents the scenario we refer to, and de-

scribes the importance of History-Based Usage con-

trol policies for regulating data usage in that scenario.

Section 3 recalls some basic notions about the UCON

Martinelli, F., Matteucci, I., Mori, P. and Saracino, A.

Concurrent History-based Usage Control Policies.

DOI: 10.5220/0006232506570666

In Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2017), pages 657-666

ISBN: 978-989-758-210-3

657

model and the U-XACML language and Section 4 re-

ports the preliminary notions of History-Based Usage

Control policies. Section 5 presents the main contri-

bution of this paper consisting of the enhanced ver-

sion of History-based Usage Control policies. This

new version is able to model and express policies to

regulate the usage of resources in more complex sce-

narios, in which concurrent behaviours has to be com-

bined together in a way to model also the interdepen-

dencies among them. Section 6 discusses about re-

lated work and Section 7 draws the conclusion of the

paper and presents our ongoing work.

2 REFERENCE EXAMPLE

In this section we deﬁne a reference example, which

will be used within the paper. Let us suppose that a

company manager M produces some strategic doc-

uments and he wants to share them with the other

employees through the (mobile) devices provided by

his company. Each of these documents is related to

a speciﬁc project of the company, thus being a valu-

able asset for the company itself. As a consequence,

M needs to regulate the usage of those documents by

deﬁning and enforcing proper security policies. At

ﬁrst, all documents written by M must be validated

both by one Legal and one Scientiﬁc representative of

the company. These two validations can be performed

in any order, even in parallel. Only after the document

has been validated both from the scientiﬁc and legal

points of view, it can be visualized by the employees

of the company. Any subject (company representative

or employee) is allowed to perform actions only on

the documents related to the set of projects assigned

to him by the manager. Moreover, we assume that the

manager wants that each employee (E) is allowed to

visualize at the same time only documents related to

the same project. The set of projects assigned to each

subject changes over time, depending on the company

needs. Hence, the right of an employee of visualiz-

ing a given document could be revoked when he is

still visualizing it. Let us suppose that an employee

E is visualizing a set of documents D concerning the

project P1. If E opens a document related to another

project, say P2, the system should interrupt the visu-

alization of the documents related to P1. The visu-

alization of the documents related to the project P1

should be interrupted also when the company man-

ager changes the set of projects assigned to the em-

ployees, and project P1 is not assigned to E anymore.

The previous example shows the importance of

having a policy language allowing:

• to express the order in which actions can be exe-

cuted. In other words, the policy should be able

to state that action B can be performed only after

action A.

• to express that the execution of some operations

can be performed in parallel (i.e., those operation

can be executed in any order, at the same time, or

one operation can be started when the other is still

in execution).

• to express the interdependence between the exe-

cution of different operations. In particular, the

execution of one operation could cause the inter-

ruption of another, which is currently in progress.

Hence, in order to satisfy the requirements of the pre-

vious scenario, we need to deﬁne one usage control

policy, UP

, which authorizes one Legal Represen-

tative (LR) of the company to perform the validation

of the documents related to the projects assigned to

him, one usage control policy, UP

, which autho-

rizes one Scientiﬁc Representatives (SR) of the com-

pany to perform the validation of the documents re-

lated to the projects assigned to him, and one us-

age control policy, UP

, which allows each employee

(E) to visualize the documents related to one of the

projects assigned to him at the same time. Moreover,

we need to combine such policies with a proper lan-

guage to state that UP

and UP

are enforced in

parallel as soon as the document has been produced,

that UP

can be enforced only after both UP

and

have been terminated, and that any number of

can be enforced in parallel.

3 USAGE CONTROL AND

U-XACML

The UCON model (Park and Sandhu, 2004; Zhang

et al., 2005) goes beyond traditional access control

ones, since it takes into account attributes of users and

objects which might change their value over time, i.e.,

mutable attributes. With reference to the example in

Section 2, the set of projects assigned to each subject

is represented in our system by a mutable attribute,

which is paired with the subject. This attribute is mu-

table because the company can update it over time ac-

cording to its needs. In particular, the value of mu-

table attributes could change while some actions are

in progress. Consequently, the UCON model allows

policy makers to write ongoing conditions and obli-

gation, i.e., rules that must be continuously satisﬁed

while the action is in progress. Hence, when the value

of an attributes changes in a such a way that one of

these ongoing rules is violated, the Usage Control pol-

icy is violated as well, and the execution of the related

AMARETTO 2017 - International Special Session on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn

658

action is properly suspended or interrupted. Ongoing

rules satisfy a requirement of the reference example,

where we need to ensure that subjects are allowed

to carry on operations only on documents related to

projects assigned to them for the whole duration of

the operation.

The U-XACML language has been deﬁned

in (Colombo et al., 2010), and it is an ex-

tension of the XACML language (OASIS, 2013)

meant to express the continuity of policy enforce-

ment required for dealing with attribute mutabil-

ity. In fact, to represent the continuity of pol-

icy enforcement, in each XACML <Condition>

and <ObligationExpression>, the U-XACML lan-

guage allows to specify when the evaluation must be

executed by adding the clause DecisionTime. The

conditions and obligations whose decision time is set

to pre are evaluated at access request time, while the

conditions and obligations whose decision time is set

to on must be continuously evaluated while the access

is in progress. Obligation can also be performed after

the end of the access, by setting the value of Decision-

Time to post.

Finally, U-XACML introduces a new element,

<AttrUpdates>, to deﬁne attribute updates. This el-

ement includes a number of <AttrUpdate> elements

to specify each update action. Each <AttrUpdate>

element also speciﬁes when the update must be per-

formed through the clause UpdateTime which can

have one of the following values: pre (the update

is performed at request time), on (the update is per-

formed while the access is in progress), and post (the

update is performed when the access is terminated).

4 FORMAL SPECIFICATION OF

A HYSTORY-BASED U-XACML

POLICY

To be able to deﬁne the allowed behaviour of the sub-

jects on the system, we exploit a process algebra to

enhance the Usage Control model with History-based

capabilities. In other words, policy makers deﬁne the

set of states of the system, and they exploit process

algebra like operators to deﬁne which Usage Con-

trol policy must be enforced in each of these states,

and the new states resulting from the enforcement of

these Usage Control policies. In this way, we sat-

isfy another requirements of the reference example

because, exploiting the history-based capabilities, the

policy can state that the visualization operation can be

executed only after the legal and scientiﬁc validation

operations.

History-based U-XACML policies have been in-

troduced in (Martinelli et al., 2016) and consist of

U-XACML policies composed through (some of) the

behavioural operators of the POlicy Language based

on Process Algebra (POLPA (Baiardi et al., 2004)).

We chose the U-XACML language to express Us-

age Control policies because it directly supports all

the features of the Usage Control model and it ben-

eﬁts from the availability of existing enforcement

tools. The POLPA language, instead, describes the

behaviour of entities in terms of allowed sequences of

processes. The idea is to use process algebra oper-

ators to combine U-XACML policies instead of pro-

cesses. This enables policy makers to have the expres-

siveness of the POLPA language, directly enforceable

through the extended XACML, which can be evalu-

ated through off-the-shelf standard tools

. It is worth

noting that the approach can be easily extended to

other PA-based languages, different from POLPA.

Let us assume that each Usage Control policy UP

is paired with one action only, α

, which can be ter-

minated either by the user (normal termination) or in-

terrupted by the system (revoked) because of a pol-

icy violation, due to updates of the values of muta-

ble attributes. For instance, the policy UP

of the

reference example regulates the action α

= VI-

SUALIZE, that can be performed by any employee

of the company. Indeed, UP

terminates with en-

dAccess if the employee explicitly ends the visual-

ization of the considered document, i.e., the execu-

tion of α

terminates normally. Instead, α

terminated by the system with revokeAccess, if, for

instance, the set of projects assigned to the employee

E changes and the documents that E is visualizing be-

long to projects no longer assigned to E. Hence, the

right to executed α

is revoked by the system as a

consequence of a change in the access context. We

model these conditions with the predicate exit(UP,r),

that holds if the policy U P has been enforced with

result r (r ∈ {endAccess,revokeAccess}). Hence:

α ::= ε k α

k α

(1)

where ε denotes no actions, α

denotes the ac-

tion α associated to the policy U P, α

is α

that

correctly ends, i.e., no policy violations occur during

the execution of the action, and α

denotes that the

execution of α

is interrupted by the system because

of a policy violation. Instead, we use α

when who

terminates the action (the user or the system) is im-

material in the policy.

A History-based U-XACML policy, hereafter de-

noted by HUP, results from the composition of

U-XACML policies and other History-based U-

http://xacmlinfo.org/category/balana/

Concurrent History-based Usage Control Policies

659

Figure 1: δ − LT S of the Usage control Policy UP

of the Reference Example.

XACML policies according to the following gram-

mar:

HU P ::= 0|U P|U P.exit(U P, r)|HU P

;HU P

|HU P

orHUP

(2)

The informal semantics is the following:

• 0 denotes that there are no more policies to en-

force;

• U P denotes the basic U-XACML policy;

• U P.exit(U P,r) is the basic policy followed by

the predicate exit stating the result of the en-

forcement of UP (speciﬁed by r, where r ∈

{endAccess,revokeAccess}). The evaluation of

exit(UP,r) depends on the function δ that works

as follows: If UP permits the execution of an ac-

tion, and this action normally terminates (α

then δ(UP) = endAccess. Instead, if this action

is interrupted because of a policy violation (α

then δ(UP) = revokeAccess. Note that, when the

evaluation UP by δ does not match the policy re-

quirement, e.g., δ(U P) = revokeAccess and the

policy is UP.exit(UP,endAccess), we assume that

no action is performed (ε) and the policy to be en-

forced does not change.

• HUP

;HUP

is the sequential operator. It rep-

resents the possibility of behaving as HUP

and

then as HUP

. Note that, both HUP

and HUP

are composed by a ﬁnite number of HUP

and

HU P

, where i, j ∈ I is a ﬁnite set of indexes.

• HUP

orHUP

is the choice operator. It repre-

sents the non deterministic choice between HUP

and HUP

. Hence, HUP

orHUP

chooses to be-

have either as HUP

or HUP

in a non determin-

istic way.

Remark 4.1. It is worth noting that each ba-

sic usage control policy UP can be written as

UP.exit(U P,endaccess) or U P.exit(U P,revokeaccess).

Indeed, the composition through the choice operator

of the two possible exit values of the policy has the

same behaviour of the UP policy without explicitly

express how it ends. Due to the one-to-one relation

between UP and α

, this is equivalent to state that

= (α

or α

) (where we exploited the same

grammar deﬁned in (2) to combine actions).

Each policy HUP can be modeled through a δ −

LTS (Labeled Transition system).

Deﬁnition 4.1 (δ − LT S for a HUP). Let HUP com-

posed by a ﬁnite number of HUP

. M = (S,Act,T ,δ)

is a δ − LT S modelling HUP, where

• S = {s|s

∪

i∈I

HU P

}, s

is the initial state;

• Act is the set of security relevant actions α of the

HU P. We consider for each action α, four labels:

ε, denoting no action, α

denotes that the action

has been terminated, α

denotes that the action

has been terminated by the user, while α

de-

notes that the action has been revoked by the sys-

tem;

• T ⊆ S × Act × S is the transition relation, driven

by the rules deﬁned in Table 1.

• δ : S → {endAccess,revokeAccess} is a labeling

function that associates the value of the exit con-

dition to the U P

enforced in that state. In prac-

tice, it is the enforcement decision function that,

by evaluation of the access request, enforces the

usage policy UP

during the execution of the ac-

tion in order to evaluate if it terminates correctly

or it is revoked.

For instance, the δ − LT S that graphically repre-

sents the policy U P

is the one depicted in Figure 1.

Each History-based Usage Control policy speci-

ﬁes its scope, which deﬁnes to which entity the state

refers to. In particular, we deﬁne three distinct scopes:

SUBJECT, OBJECT, or GLOBAL.

If the scope is SUBJECT, each subject of the

scenario has his own state, and distinct subjects are

paired to distinct states. Hence, when a subject s tries

to perform an action, the system takes into account

the state paired with s to select the set of Usage Con-

trol policies to be enforced, and updates this state as

AMARETTO 2017 - International Special Session on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn

660

Table 1: Semantics rules for inferring the admissible behaviour of HUP.

Basic Case.

−→ 0

endAccess.

δ(UP) = endAccess

UP.exit(U P,endAccess)

−→ 0

δ(UP) = revokeAccess

UP.exit(U P,endAccess)

−→ UP.exit(UP,endAccess)

revokeAccess.

δ(UP) = endAccess

UP.exit(U P,revokeAccess)

−→ UP.exit(UP,revokeAccess)

δ(UP) = revokeAccess

UP.exit(U P,revokeAccess)

−→ 0

Preﬁx.

HU P

−→ HUP

HU P

;HUP

−→ HUP

;HUP

HU P

−→ HUP

0;HUP

−→ HUP

Choice.

HU P

−→ HUP

HU P

orHUP

−→ HUP

HU P

−→ HUP

HU P

orHUP

−→ HUP

a consequence of the action. Thus, the current state

paired to subject s depends on the actions that s per-

formed on the objects of the system.

Instead, if the policy scope is OBJECT, each ob-

ject of the scenario has its own state. In this case,

when a subject wants to access an object o, is the

state paired with o, which determines the set of Us-

age Control policies that must be enforced. The ac-

tion performed by any subject on the object o results

in an update of the state paired to o.

Finally, if the scope is GLOBAL the state is

shared, i.e., the actions performed by all the subjects

on all the objects affect the same state.

5 CONCURRENT

HYSTORY-BASED U-XACML

POLICY

To fulﬁl the requirements deﬁned in Section 2, in this

paper we extend the History-based U-XACML policy

language introduced in (Martinelli et al., 2016) and

recalled in Section 4, in which the process-algebra

like operators deﬁned by the POLPA language are ex-

ploited to combine Usage Control policies expressed

with the U-XACML policy language. In particular, in

this paper we introduce the parallel operator, which

allows to express the behaviour of a system through

the concurrent application of different policies.

The parallel composition of two History-based

Usage Control policies HUP extends the grammar in

(2) and it is expressed as follows:

HU P ::= HUPk

HU P

where L is a subset of Act, the set of security rel-

evant actions, on which the two policies synchronize

their behaviour. In particular, the parallel operator al-

lows the two policies to proceed in parallel and even-

tually coordinate on the set of actions L. Furthermore,

we need to reﬁne Deﬁnition 1 of actions α ∈ Act by

introducing α

as follows:

α ::= ε k α

k α

(3)

where α

denotes the beginning of the action

, which is called startAccess in Usage Control.

Hence, each action α

is ﬁrst started (α

), and then

terminated either by the user (α

), or it is interrupted

by the system (α

). This helps us to be more precise

in modeling the behavior of concurrent usage control

policies that may start to be evaluated concurrently.

Recalling the example and Remark 4.1, the policy

is:

= UP

.exit(UP

,endaccess)

or UP

.exit(UP

,revokeaccess)

since, both UP

.exit(UP

,endaccess) and

.exit(UP

,revokeaccess) are now reﬁned as

follows:

.exit(UP

,endaccess) = α

;α

and:

.exit(UP

,revokeaccess) = α

;α

Concurrent History-based Usage Control Policies

661

Table 2: Reﬁned endAccess semantics rule.

δ(UP) = endAccess

UP.exit(U P,endAccess)

;α

−→ 0

δ(UP) = revokeAccess

UP.exit(U P,endAccess)

−→ UP.exit(UP,endAccess)

Table 3: Parallel operator semantics rule.

HU P

−→ HUP

HU P

−→ HUP

HU P

/∈ L

HU P

−→ HUP

HU P

−→ HUP

HU P

/∈ L

HU P

−→ HUP

HU P

−→ HUP

HU P

−→ HUP

HU P

∈ L

then:

= α

;α

or α

;α

(4)

This leads to a further reﬁnement of the seman-

tics rules describing the Basic case, endAccess, and

revokeAccess case given in Table 1. For instance, the

endAccess rule is reﬁned as in Table 2.

It is worth noting that the reﬁned deﬁnition of UP

in Equation 4 can be written as a deterministic pro-

cess, as it is represented in Figure 2:

= α

;(α

or α

) (5)

As usual for process description languages, other

operators may be derived. By using the con-

stant deﬁnition, the sequence and the derived par-

allel operators, the iteration and replication opera-

tors, it

(HU P) and rec(HU P) resp., can be de-

rived. Informally, it

(HU P) behaves as the iter-

ation of HUP n times, where n can also be zero,

(HU P; HU P; .. .; HU P), while rec(HUP) is the par-

allel composition of the same process an unbounded

number of times (HU Pk

HU Pk

.. .k

HU P).

Recalling the Reference Example. With reference

to the example described in Section 2, we deﬁne the

following usage control policies:

• U P

is the usage control policy regulating the ex-

ecution of the scientiﬁc validation of a document

by a Scientiﬁc Representative of the company (the

U-XACML representation of UP

is shown as an

example in Table 5).

• U P

is the usage control policy regulating the ex-

ecution of the legal validation of a document by a

Legal Representative of the company.

• U P

is the usage control policy regulating the vi-

sualization of a document by an employee of the

company.

In order to satisfy the requirements of the refer-

ence example, we deﬁne a History-based usage con-

trol policy, HUP, by combining the previous poli-

cies through the operators of the POLPA language

described in this section and in Section 4. Since we

are interested in regulating the usage of each docu-

ment by any of the subjects of the scenario, the scope

of HUP is set to OBJECT. Consequently, each doc-

ument has its own state, which is represented by a

mutable attribute of the object itself, and each action

performed on this document by any subject of the

scenario changes this state. In this way, HUP states

that the usage control policies UP

and U P

are en-

forced in parallel (i.e., the scientiﬁc and the legal val-

idation can be performed concurrently, started in any

order), and that the policy UP

is enforced only af-

ter the scientiﬁc and legal validations have success-

fully terminated. Table 4 shows the History-based U-

XACML policy for the reference example.

The ﬁrst two lines of HUP (lines l1 and l2) con-

cern the scientiﬁc validation of the document. In par-

ticular, the policy rule in line l2 states that the Sci-

entiﬁc Representative of the company is allowed to

perform the validation of the document. This rule

is combined through the sequence operator with the

rule in line l1, which states that the scientiﬁc vali-

dation process can be started by a Scientiﬁc Repre-

sentative and then revoked by the system any num-

ber of times (represented by n in the policy), before

being successfully executed, i.e., terminated by the

user ((UP

.exit(UP

,endAccess))). The value of n

is equal to 0 when the ﬁrst attempt of scientiﬁc vali-

dation is carried out successfully. The rules in lines

l4 and l5 are equivalent to the rules in lines l1 and

l2. The only difference is that they concern the legal

validation which can be performed by a Legal Rep-

resentative of the company. The parallel operator in

line l3 is aimed at allowing the concurrent execution

of the scientiﬁc validation (lines l1-l2) and the legal

validation (lines l4-l5).

Finally, the sequential operator in line l6 is aimed

at allowing the visualization of the document by em-

ployees only after the termination of the parallel ex-

ecution of the scientiﬁc and legal validations (l1-l5).

Moreover, the document visualization allowed by the

usage control policy UP

can be performed in paral-

lel any number of times, since UP

is included in a

replication operation (rec(UP

)).

AMARETTO 2017 - International Special Session on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn

662

Figure 2: δ − LT S of the Usage control Policy UP

in Equation 5.

Table 4: History-based Usage Control Policy for the Reference Example.

l1 HUP = ( ( it

(UP

.exit(UP

,revokeAccess));

l2 (UP

.exit(UP

,endAccess)))

l3 k

l4 ( it

(UP

.exit(UP

,revokeAccess));

l5 (UP

.exit(UP

,endAccess)))

l6 );

l7 rec(UP

)

Figure 3: δ − LT S of the Usage control Policy HUP of the Reference Example.

Figure 3 represents the δ-LTS of the Hystory

Based Usage Control Policy speciﬁed in Table 4. For

the sake of readability, in the ﬁgure we omit to ex-

plicitly describe the conditions on states that consent

the transition from a state to another with a speciﬁc

action.

It is worth to specify that the proposed model does

not consider deadlock issues or critical race condi-

tions. In fact, such issues are not related directly to

the model, but to the policy design. A badly writ-

ten policy can indeed bring non-managed critical race

conditions, which might be object of investigation in

future work.

Concurrent History-based Usage Control Policies

663

6 RELATED WORK

First deﬁnition of the Usage Control model has been

proposed by Sandhu et al. in (Park and Sandhu,

2004), whilst a ﬁrst application on collaborative com-

puting system is discussed in (Zhang et al., 2008).

A recent work on application of Usage Control for

handling ongoing access on data has been proposed

in (Lazouski et al., 2016). The proposed framework

has been designed and implemented for Android de-

vices, partially leveraging on native security mecha-

nisms and the presence of a TPM for integrity man-

agement. This work is based on standard Usage Con-

trol, i.e., does not leverage history-based policies, in

an environment such as smartphones where the higher

expressiveness of History-Based policies, could bring

a noticeable beneﬁt.

In (Kelbert and Pretschner, 2014) Kelbert and

Pretschner present an application of Usage Control

to distributed and multi domain systems. In the pre-

sented work, the authors assume that data can travel

across different domains where the same policy has

to be enforced. Also this application can beneﬁt from

the extension to Usage Control presented in the cur-

rent work, deﬁning conditions where usage is granted

only if the speciﬁc data has been ﬁrst opened and

then archived by a speciﬁc sequence of agents of the

distributed system. From the same authors, another

framework which is speciﬁc for data Usage Con-

trol is presented in (Kelbert and Pretschner, 2015).

This framework offers a decentralized and distributed

enforcement infrastructure, which however does not

consider and enforce history-based policies.

On the formal aspects, the ConSpec language,

presented in (Aktug and Naliuka, 2008) is another

language which can express history-based policies.

ConSpec can be expressed either as a labeled tran-

sition system or in a text form. However, the Con-

Spec language is not compliant with standards, shar-

ing thus the same strength and weaknesses shown in

the POLPA language.

The POLPA language has been previously

adopted in (Martinelli and Mori, 2007) for improv-

ing the Java native security support by enabling the

enforcement of history-based access control policies.

Instead, a proposal of history-based Usage Control

system entirely based on the POLPA language is pre-

sented (Martinelli and Mori, 2010). However, writing

policies in POLPA dealing also with Usage Control

features, is not straightforward.

The approach proposed in this paper, which pro-

poses to write the Usage Control policies in U-

XACML and exploits POLPA to combine them, eases

the work of policy makers.

7 CONCLUSION

In this paper we extended the formal approach pre-

sented in (Martinelli et al., 2016) which deﬁnes a His-

tory based U-XACML Usage Control policy language

by combining U-XACML policies through the oper-

ators of the POLPA language. The proposed exten-

sion to the language allows the enforcement of two

(or more) Usage Control policies in parallel, i.e., the

related operations can be executed in any order and an

operation can be started when the other(s) is (are) still

in execution. We also presented a motivating exam-

ple, where a company needs to regulate the usage of

a document shared among a set of employees, and we

show that the proposed language can be successfully

exploited to deﬁne the policy which encodes the set

of sharing requirements.

As ongoing work, we are implementing the pro-

posed framework to validate it and evaluate it in terms

of its performance.

ACKNOWLEDGEMENTS

This work was partially supported by the H2020 EU

funded project NeCS [GA #675320], by the H2020

EU funded project C3ISP [GA #700294], and by the

EIT Digital High Impact Initiative #14605 Trusted

Data Management with Service Ecosystem.

REFERENCES

Aktug, I. and Naliuka, K. (2008). ConSpec - A formal lan-

guage for policy speciﬁcation. Science of Computer

Programming. Special Issue on Security and Trust,

74(1):2 – 12.

Baiardi, F., Martinelli, F., Mori, P., and Vaccarelli, A.

(2004). Improving grid services security with ﬁne

grain policies. In On the Move to Meaningful Internet

Systems 2004: Confederated International Workshops

and Posters, GADA, JTRES, MIOS, WORM, WOSE,

PhDS, and INTEROP 2004, Agia Napa, Cyprus, Oc-

tober 25-29, 2004. Proceedings, pages 123–134.

Colombo, M., Lazouski, A., Martinelli, F., and Mori, P.

(2010). A proposal on enhancing xacml with continu-

ous usage control features. In Grids, P2P and Services

Computing, pages 133–146, Boston, MA. Springer

US.

Kelbert, F. and Pretschner, A. (2014). Decentralized dis-

tributed data usage control. In Cryptology and Net-

work Security: 13th International Conference, CANS

2014, Heraklion, Crete, Greece, October 22-24, 2014.

Proceedings, pages 353–369, Cham. Springer Interna-

tional Publishing.

AMARETTO 2017 - International Special Session on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn

664

Kelbert, F. and Pretschner, A. (2015). A fully decentral-

ized data usage control enforcement infrastructure. In

Applied Cryptography and Network Security: 13th In-

ternational Conference, ACNS 2015, New York, NY,

USA, June 2-5, 2015, Revised Selected Papers, pages

409–430, Cham. Springer International Publishing.

Lazouski, A., Martinelli, F., Mori, P., and Saracino, A.

(2014). Stateful usage control for android mobile de-

vices. In Security and Trust Management - 10th In-

ternational Workshop, STM 2014, Wroclaw, Poland,

September 10-11, 2014. Proceedings, pages 97–112.

Lazouski, A., Martinelli, F., Mori, P., and Saracino, A.

(2016). Stateful data usage control for android mobile

devices. International Journal of Information Secu-

rity, pages 1–25.

Martinelli, F., Matteucci, I., Mori, P., and Saracino, A.

(2016). Enforcement of U-XACML history-based us-

age control policy. In Security and Trust Management

- 12th International Workshop, STM 2016, Heraklion,

Crete, Greece, September 26-27, 2016, Proceedings,

volume 9871 of Lecture Notes in Computer Science,

pages 64–81. Springer.

Martinelli, F. and Mori, P. (2007). Enhancing java secu-

rity with history based access control. In Foundations

of Security Analysis and Design IV, pages 135–159.

Springer-Verlag.

Martinelli, F. and Mori, P. (2010). On usage control for

grid systems. Future Generation Computer Systems,

26(7):1032–1042.

Neisse, R., Pretschner, A., and Di Giacomo, V. (2013). A

trustworthy usage control enforcement framework. In-

ternational Journal of Mobile Computing and Multi-

media, 5(3):34–49.

OASIS (2013). eXtensible Access Control Markup Lan-

guage (XACML) Ver. 3.0.

Park, J. and Sandhu, R. (2004). The UCON

ABC

usage con-

trol model. ACM Transactions on Information and

System Security, 7:128–174.

Zhang, X., Nakae, M., Covington, M. J., and Sandhu, R.

(2008). Toward a usage-based security framework for

collaborative computing systems. ACM Transactions

on Information and System Security, 11(1):3:1–3:36.

Zhang, X., Parisi-Presicce, F., Sandhu, R., and Park, J.

(2005). Formal model and policy speciﬁcation of us-

age control. ACM Transactions on Information and

System Security, 8(4):351–387.

Concurrent History-based Usage Control Policies

665

Table 5: Usage Control Policy UP

<?xml version="1.0" encoding="UTF-8"?>

<Policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17

http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd" PolicyId="UP_SR"

RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"

Version="3.0">

<AnyOf>

<AllOf>

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Validate

</AttributeValue>

<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"

Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"

DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true">

</AttributeDesignator>

</Match>

</AllOf>

</AnyOf>

</Target>

<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:3.0:subject:role"

Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true">

</AttributeDesignator>

</Apply>

ScientificRepresentative</AttributeValue>

</Apply>

<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:3.0:subject:assigned-proj"

Category="urn:oasis:names:tc:xacml:3.0:attribute-category:access-subject"

DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true">

</AttributeDesignator>

</Apply>

<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:3.0:resource:project"

Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true">

</AttributeDesignator>

</Apply>

</Condition>

<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:3.0:subject:assigned-proj"

Category="urn:oasis:names:tc:xacml:3.0:attribute-category:access-subject"

DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true">

</AttributeDesignator>

</Apply>

<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:3.0:resource:project"

Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true">

</AttributeDesignator>

</Apply>

</Condition>

</Rule>

</Policy>

AMARETTO 2017 - International Special Session on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn

666