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 first, 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 influence
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 defined 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 satisfied 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 define 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
fields 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 specific
(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
Copyright © 2017 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
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 define 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 specific 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
defining and enforcing proper security policies. At
first, all documents written by M must be validated
both by one Legal and one Scientific 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 scientific 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 define one usage control
policy, UP
LR
, 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
SR
, which autho-
rizes one Scientific 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
E
, 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
LR
and UP
SR
are enforced in
parallel as soon as the document has been produced,
that UP
E
can be enforced only after both UP
LR
and
UP
SR
have been terminated, and that any number of
UP
E
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 satisfied
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 specific Model-based AppRoaches to vErificaTion 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 defined
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 define attribute updates. This el-
ement includes a number of <AttrUpdate> elements
to specify each update action. Each <AttrUpdate>
element also specifies 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 define 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 define the
set of states of the system, and they exploit process
algebra like operators to define 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 scientific 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-
efits 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
1
. 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, α
UP
, 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
E
of the
reference example regulates the action α
UP
E
= VI-
SUALIZE, that can be performed by any employee
of the company. Indeed, UP
E
terminates with en-
dAccess if the employee explicitly ends the visual-
ization of the considered document, i.e., the execu-
tion of α
UP
E
terminates normally. Instead, α
UP
E
is
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 α
UP
E
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 α
UP
k α
ea
UP
k α
ra
UP
(1)
where ε denotes no actions, α
UP
denotes the ac-
tion α associated to the policy U P, α
ea
UP
is α
UP
that
correctly ends, i.e., no policy violations occur during
the execution of the action, and α
ra
UP
denotes that the
execution of α
UP
is interrupted by the system because
of a policy violation. Instead, we use α
UP
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-
1
http://xacmlinfo.org/category/balana/
Concurrent History-based Usage Control Policies
659
Figure 1: δ LT S of the Usage control Policy UP
E
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
1
;HU P
2
|HU P
1
orHUP
2
(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 (specified 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 (α
ea
UP
),
then δ(UP) = endAccess. Instead, if this action
is interrupted because of a policy violation (α
ra
UP
),
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
1
;HUP
2
is the sequential operator. It rep-
resents the possibility of behaving as HUP
1
and
then as HUP
2
. Note that, both HUP
1
and HUP
2
are composed by a finite number of HUP
1
i
and
HU P
2
j
, where i, j I is a finite set of indexes.
HUP
1
orHUP
2
is the choice operator. It repre-
sents the non deterministic choice between HUP
1
and HUP
2
. Hence, HUP
1
orHUP
2
chooses to be-
have either as HUP
1
or HUP
2
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 α
UP
, this is equivalent to state that
α
UP
= (α
ea
UP
or α
ra
UP
) (where we exploited the same
grammar defined in (2) to combine actions).
Each policy HUP can be modeled through a δ
LTS (Labeled Transition system).
Definition 4.1 (δ LT S for a HUP). Let HUP com-
posed by a finite number of HUP
i
. M = (S,Act,T ,δ)
is a δ LT S modelling HUP, where
S = {s|s
0
S
iI
S
HU P
i
}, s
0
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, α
UP
i
denotes that the action
has been terminated, α
ea
UP
i
denotes that the action
has been terminated by the user, while α
ra
UP
i
de-
notes that the action has been revoked by the sys-
tem;
T S × Act × S is the transition relation, driven
by the rules defined in Table 1.
δ : S {endAccess,revokeAccess} is a labeling
function that associates the value of the exit con-
dition to the U P
i
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
i
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
E
is the one depicted in Figure 1.
Each History-based Usage Control policy speci-
fies its scope, which defines to which entity the state
refers to. In particular, we define 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 specific Model-based AppRoaches to vErificaTion and validaTiOn
660
Table 1: Semantics rules for inferring the admissible behaviour of HUP.
Basic Case.
UP
α
UP
0
endAccess.
δ(UP) = endAccess
UP.exit(U P,endAccess)
α
ea
UP
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)
α
ra
UP
0
Prefix.
HU P
1
α
HUP
0
1
HU P
1
;HUP
2
α
HUP
0
1
;HUP
2
HU P
2
α
HUP
0
2
0;HUP
2
α
HUP
0
2
Choice.
HU P
1
α
HUP
0
1
HU P
1
orHUP
2
α
HUP
0
1
HU P
2
α
HUP
0
2
HU P
1
orHUP
2
α
HUP
0
2
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 fulfil the requirements defined 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 defined 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
L
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 refine Definition 1 of actions α Act by
introducing α
sa
UP
as follows:
α ::= ε k α
UP
k α
sa
UP
k α
ea
UP
k α
ra
UP
(3)
where α
sa
UP
denotes the beginning of the action
α
UP
, which is called startAccess in Usage Control.
Hence, each action α
UP
is first started (α
sa
UP
), and then
terminated either by the user (α
ea
UP
), or it is interrupted
by the system (α
ra
UP
). 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
UP
E
is:
UP
E
= UP
E
.exit(UP
E
,endaccess)
or UP
E
.exit(UP
E
,revokeaccess)
since, both UP
E
.exit(UP
E
,endaccess) and
UP
E
.exit(UP
E
,revokeaccess) are now refined as
follows:
UP
E
.exit(UP
E
,endaccess) = α
sa
UP
E
;α
ea
UP
E
and:
UP
E
.exit(UP
E
,revokeaccess) = α
sa
UP
E
;α
ra
UP
E
Concurrent History-based Usage Control Policies
661
Table 2: Refined endAccess semantics rule.
δ(UP) = endAccess
UP.exit(U P,endAccess)
α
sa
UP
;α
ea
UP
0
δ(UP) = revokeAccess
UP.exit(U P,endAccess)
ε
UP.exit(UP,endAccess)
Table 3: Parallel operator semantics rule.
HU P
1
α
UP
HUP
0
1
HU P
1
k
L
HU P
2
α
UP
HUP
0
1
k
L
HU P
2
α
UP
/ L
HU P
2
α
UP
HUP
0
2
HU P
1
k
L
HU P
2
α
UP
HUP
1
k
L
HU P
0
2
α
UP
/ L
HU P
1
α
UP
HUP
0
1
HU P
2
α
UP
HUP
0
2
HU P
1
k
L
HU P
2
α
UP
HUP
0
1
k
L
HU P
0
2
α
UP
L
then:
UP
E
= α
sa
UP
E
;α
ea
UP
E
or α
sa
UP
E
;α
ra
UP
E
(4)
This leads to a further refinement of the seman-
tics rules describing the Basic case, endAccess, and
revokeAccess case given in Table 1. For instance, the
endAccess rule is refined as in Table 2.
It is worth noting that the refined definition of UP
E
in Equation 4 can be written as a deterministic pro-
cess, as it is represented in Figure 2:
UP
E
= α
sa
UP
E
;(α
ea
UP
E
or α
ra
UP
E
) (5)
As usual for process description languages, other
operators may be derived. By using the con-
stant definition, the sequence and the derived par-
allel operators, the iteration and replication opera-
tors, it
n
(HU P) and rec(HU P) resp., can be de-
rived. Informally, it
n
(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
/
0
HU Pk
/
0
.. .k
/
0
HU P).
Recalling the Reference Example. With reference
to the example described in Section 2, we define the
following usage control policies:
U P
SR
is the usage control policy regulating the ex-
ecution of the scientific validation of a document
by a Scientific Representative of the company (the
U-XACML representation of UP
SR
is shown as an
example in Table 5).
U P
LR
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
E
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 define 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
SR
and U P
LR
are en-
forced in parallel (i.e., the scientific and the legal val-
idation can be performed concurrently, started in any
order), and that the policy UP
E
is enforced only af-
ter the scientific and legal validations have success-
fully terminated. Table 4 shows the History-based U-
XACML policy for the reference example.
The first two lines of HUP (lines l1 and l2) con-
cern the scientific validation of the document. In par-
ticular, the policy rule in line l2 states that the Sci-
entific 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 scientific vali-
dation process can be started by a Scientific 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
SR
.exit(UP
SR
,endAccess))). The value of n
is equal to 0 when the first attempt of scientific 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 scientific 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 scientific and legal validations (l1-l5).
Moreover, the document visualization allowed by the
usage control policy UP
E
can be performed in paral-
lel any number of times, since UP
E
is included in a
replication operation (rec(UP
E
)).
AMARETTO 2017 - International Special Session on domAin specific Model-based AppRoaches to vErificaTion and validaTiOn
662
Figure 2: δ LT S of the Usage control Policy UP
E
in Equation 5.
Table 4: History-based Usage Control Policy for the Reference Example.
l1 HUP = ( ( it
n
(UP
SR
.exit(UP
SR
,revokeAccess));
l2 (UP
SR
.exit(UP
SR
,endAccess)))
l3 k
/
0
l4 ( it
m
(UP
LR
.exit(UP
LR
,revokeAccess));
l5 (UP
LR
.exit(UP
LR
,endAccess)))
l6 );
l7 rec(UP
E
)
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 specified in Table 4. For
the sake of readability, in the figure we omit to ex-
plicitly describe the conditions on states that consent
the transition from a state to another with a specific
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 definition of the Usage Control model has been
proposed by Sandhu et al. in (Park and Sandhu,
2004), whilst a first 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 benefit.
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 benefit from
the extension to Usage Control presented in the cur-
rent work, defining conditions where usage is granted
only if the specific data has been first opened and
then archived by a specific sequence of agents of the
distributed system. From the same authors, another
framework which is specific 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 defines 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 define 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 specification. 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 fine
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 specific Model-based AppRoaches to vErificaTion 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 specification 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
SR
.
<?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">
<Target/>
<Rule Effect="Permit" RuleId="rule1">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<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>
<Condition DecisionTime="pre">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
<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>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
ScientificRepresentative</AttributeValue>
</Apply>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
<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>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
<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>
</Apply>
</Apply>
</Condition>
<Condition DecisionTime="on">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
<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>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
<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>
</Apply>
</Condition>
</Rule>
</Policy>
AMARETTO 2017 - International Special Session on domAin specific Model-based AppRoaches to vErificaTion and validaTiOn
666