Dynamic Analysis of Usage Control Policies
Yehia Elrakaiby
1
and Jun Pang
2
1
Fraunhofer IESE, Fraunhofer-Platz 1, 67663 Kaiserslautern, Kaiserslautern, Germany
2
University of Luxembourg, 6 rue Richard Coudenhove-Kalergi, Luxembourg, Luxembourg
Keywords:
Usage Control, Access Control, Policy Analysis, Formal Verification.
Abstract:
Usage control extends access control by enabling the specification of requirements that should be satisfied
before, while and after access. To ensure that the deployment of usage control policies in target domains
achieves the required security goals, policy verification and analysis tools are needed. In this paper, we present
an approach for the dynamic analysis of usage control policies using formal descriptions of target domains
and their usage control policies. Our approach provides usage control management explicit labeled transition
system semantics and enables the automated verification of usage control policies using model checking.
1 INTRODUCTION
Access control aims at protecting information sys-
tems against unauthorized accesses. Usage control
extends access control with the support of pre-access,
ongoing-access and post-access controls, enabling the
expression of more fine-grained controls on access
operations. More specifically, usage controls allows
specification of before-access, while-access and after-
access requirements, typically in the form of either
required user actions, e.g. acceptance of an applica-
tion’s usage terms prior to access, or some state con-
ditions that should be maintained, e.g. to keep an ad
window open during access.
A security policy formally specifies rules needed
to satisfy the security requirements of a given infor-
mation system. Therefore, the overall system security
depends on its correct expression. Indeed, misspeci-
fied policies could allow undesirable security vulnera-
bilities and compromise the overall goals that security
policies aim to achieve.
Two main analysis types are used for verification
of security policies. Static analysis typically checks
policy structure to verify policy consistency (Lupu
and Sloman, 1999; Simon and Zurko, 1997). Dy-
namic policy analysis takes into account policy state
evolution, i.e. the possible policy states that can be
reached after, for example, the execution of policy
administration actions (Li and Tripunitara, 2006), ac-
cess requests (Becker and Nanz, 2007), or general ac-
tions (Craven et al., 2009). Dynamic analysis thus
checks the satisfaction of the desired policy properties
in every possible (reachable) state. Dynamic policy
analysis has been used for the verification of access
control policies (Li and Tripunitara, 2006; Becker and
Nanz, 2007), and obligation policies (Craven et al.,
2009). However, the dynamic analysis of usage con-
trol policies remains, to the best of our knowledge,
unexplored. An overview of formal security policy
analysis is presented in Section 6.
This paper introduces an approach for the dy-
namic analysis of usage control policies that consists
of first (1) making a formal description of the target
domain and its usage policy using the action language
C+ (Giunchiglia et al., 2004), a recent member of
the family of action languages (Gelfond and Lifschitz,
1998), and then (2) using model checking techniques
to verify the properties of the specified usage con-
trol policy. Our work also formalizes usage control
management, e.g. activation and cancellation of us-
age controls and the management of usage sessions,
clarifying the enforcement of usage controls and en-
abling the use of standard model-checking techniques
for the verification of usage control policy properties.
2 ACTION LANGUAGE C+
The action language C+ (Sergot, 2004) is a mem-
ber of the family of action languages (Gelfond and
Lifschitz, 1998). C+ has explicit transition sys-
tem semantics and allows a natural expression of
many things such as inertia, concurrent actions, non-
determinism and ramifications. The practicality of
88
Elrakaiby Y. and Pang J..
Dynamic Analysis of Usage Control Policies.
DOI: 10.5220/0005046600880100
In Proceedings of the 11th International Conference on Security and Cryptography (SECRYPT-2014), pages 88-100
ISBN: 978-989-758-045-1
Copyright
c
 2014 SCITEPRESS (Science and Technology Publications, Lda.)

C+ is demonstrated by its use in diverse application
domains (Armando et al., 2009; Armando et al., 2012;
Artikis et al., 2007; Son et al., 2012; Dworschak et al.,
2008; Artikis and Sergot, 2010). Several planning and
model checking tools for the automated analysis of
C+ specifications are available (CCa, ; iCC, ; Lifs-
chitz, 1999; Gebser et al., 2010; Casolary, 2011; Babb
and Lee, 2013).
For the description of dynamic domains, C+ pro-
vides two disjoint non-empty sets of atoms, namely
a set of simple actions (A) and a set of fluents (F ).
Intuitively, fluents are propositions used to describe
the state of the world. Actions are used to represent
events that change the state of the world.
2.1 Basic Definitions
A multi-valued propositional signature is a set σ of
symbols called constants, where each constant c ∈ σ
is associated with a non-empty set of symbols, dis-
joint from σ, called the domain of c. An atom of sig-
nature σ is an expression of the form c = u, where
c ∈ σ and u ∈ dom(c). For instance, a Boolean con-
stant is one whose domain is the set of truth values
{t, f}. When c is a Boolean constant, c = t is sim-
ply written as c and c = f is written ¬c. A formula
φ of signature σ is any propositional combination of
atoms of σ. An interpretation I of σ is a function
that maps every constant in σ to an element of its do-
main. An interpretation I satisfies an atom c = u if
I(c) = u. The satisfaction relation is extended from
atoms to formulas, according to the standard truth ta-
bles for the propositional connectives. A model of a
set X of formulas of signature σ is an interpretation
of σ that satisfies all formulas in X. If every model of
a set X of formulas satisfies some formula φ then X
entails φ, written as X |= φ.
2.2 C+ Syntax
An action signature (σ
f
, σ
a
) is partitioned into a non-
empty set σ
f
of fluent constants and another non-
empty set σ
a
of action constants. Fluents are fur-
ther divided into statically determined fluents (σ
st
)
and simple fluents (σ
si
). Fluent constants are sym-
bols characterizing a state, whereas action constants
characterize state transitions.
An action description D is a non-empty set of
causal laws. Causal laws of an action description
define a transition system by specifying relationships
between fluents and actions. A causal law is a propo-
sition of one of the following forms:
static law: CAUSED F IF G
dynamic law: CAUSED F IF G AFTER H
action dynamic law: CAUSED α IF H
where F and G are formulas of σ
f
such that F does
not include any statically determined fluent constants,
α is an action formula and H is any combination of
fluent and action constants. A static law specifies that
if G is true in a state, then F is caused to be true. Thus,
static laws describe relationships between fluent con-
stants in an individual state. A dynamic law describes
relationships between actions and fluents in state tran-
sitions: in a transition from a state s
i
to another state
s
i+1
, constants in F and G of a dynamic law are eval-
uated on s
i+1
, fluent constants in H are evaluated on s
i
and action constants in H are evaluated on the transi-
tion itself. An action dynamic law specifies that when
G is true in a state, then when the system evolves from
that state, it must do so in a way which makes α true,
namely α is evaluated on the transition. The formula
F of a causal law is called its head. In the following,
the keyword CAUSED will not be used for readability.
Several common abbreviations of C+ proposi-
tions are used to model action preconditions, action
non-determinism, fluents with default values, inertial
and exogenous fluents. Abbreviations of C+ propo-
sitions used in this paper are shown in Table 1. Note
that the if part of a rule may be omitted if it is true.
Also, similarly to fluents in Table 1, action constants
can be exogenous. An exogenous action may occur at
any state.
Definite action descriptions are the most practical
ones since it is straightforward to find runs through
transition systems defined by them. An action de-
scription D is definite if:
1. the head of every causal law of D is an atom or ⊥;
2. no atom is the head of infinitely many causal laws.
2.3 C+ Semantics
AC+ action description D defines a labeled transition
system TS = hS, L, →i, where S is a set of states, L is
a set of labels and →⊆ S × L × S is a transition rela-
tion between states. The set of states and the labels
of TS are interpretations of σ
f
and σ
a
, respectively.
The states and transitions of TS are constrained by
the causal laws in D in the following way:
• A state s of TS is an interpretation of σ
f
iff s sat-
isfies the set of formulas T
st
(s) ∪ Simple(s) and
there is no other interpretation of σ
f
which satis-
fies this set, i.e.,
{s} = {s
′
∈ I(σ
f
) | s
′
|= T
st
(s) ∪ Simple(s)}
• A label is an interpretation I(σ
a
) of σ
a
.
DynamicAnalysisofUsageControlPolicies
89

Table 1: Common Abbreviations for Causal Laws.
Abbreviation Expanded Form Informal Meaning
NONEXECUTABLE H IF F ⊥ AFTER H ∧F F is a precondition of H
H CAUSES F IF G F IF ⊤ AFTER G∧ H F is true after H is executed in a state in which G is true
INERTIAL F F IF F AFTER F,
¬F IF ¬F AFTER ¬F
F keeps its value after a transition if its value is not affected
by the transition
DEFAULT F F IF F F is true in the absence of information to the contrary
EXOGENOUS F DEFAULT F, DEFAULT ¬F F may be true or false in any state
F IFF G F IF G, DEFAULT ¬F F is true only if G is true
• A transition (s, e, s
′
) is a transition of TS iff both s
and s
′
are states of D, e is label of D and
{s
′
} = {s
′′
∈ I(σ
f
) | s
′′
|= T
st
(S
′
) ∪ E(s, e, s
′
)}
{e} = {e
′
∈ I(σ
a
) | e
′
|= A(s, e)}
where T
st
, E, A and Simple are defined as follows:
T
st
(s) = {F | “F IF G” ∈ D, s |= G}
E(s, e, s
′
) = {F | “F IF G AFTER H” ∈ D, s
′
|= G,
s∪ e |= H}
A(s, e) = {A | “α IF G” ∈ D, s∪ e |= G}
Simple(s) = {c = v | c ∈ σ
si
, s |= c = v}
An example description of a labeled transition system
using C+ is presented in the appendix.
3 POLICY SPECIFICATION
Our approach for the dynamic analysis of usage con-
trol policies is composed of two steps: the target do-
main is first described as an action description D and
its usage control policy P
U
is separately specified us-
ing the usage control policy language presented in
Section 3.1. Given the target action description and
its usage policies, a new action description, denoted
D
P
U
, is constructed to model the target domain when
the specified usage policies are enforced in it, as ex-
plained in Section 4. Given D
P
U
, we are able to auto-
mate the verification of usage control policy proper-
ties as discussed in Section 5.
To illustrate our approach, we use as running ex-
ample a movie player application iX. The users of iX
can turn the application on, play movies and turn the
application off. The users can also accept the appli-
cation usage terms, pay for movies and close an ad
window that appears when a movie is played. Users
of iX may have different roles, e.g., a user can be a
privileged user or a blacklisted user. In the following,
this example is referred to as Example 1.
Table 2: Fluent Constants.
Fluent Constant Informal Meaning
ad window the ad-window is open.
payment
window the payment-window is open.
terms
window the terms-window is open.
terms
accepted the application terms are accepted.
user
role the role of the user requesting access.
state the movie application state.
Table 3: Action Constants.
Action Constant Informal Meaning
turn on turns on the application.
quit quits the application.
play plays a movie.
stop stops the movie.
accept
terms accept the application usage terms.
pay pay for a movie.
close
ad closes the ad-window.
To formally describe iX, we consider an action
description with a signature that includes the inertial
fluent constants shown in Table 2 and action constants
shown in Table 3. All fluent constants in the signature
are Boolean with the exception of state, whose do-
main is {off, on, playing}, and user
role, whose do-
main is {regular, privileged, blacklisted}. All action
constants are exogenous.
Actions of the action description and their exe-
cutability conditions are described using causal laws.
For example, the following rules specify that the ex-
ecution of the action accept
terms makes the fluent
terms accepted true and the fluent ad window false;
and that the action accept
terms cannot be executed if
the payment window is not active:
accept
terms CAUSES terms accepted
accept
terms CAUSES ¬ad window
NONEXECUTABLE accept terms IF ¬terms window
The full action description is given in the appendices.
In the following, the set of fluents and actions of the
action description of the target domain will be de-
SECRYPT2014-InternationalConferenceonSecurityandCryptography
90

noted by F and A , and will be called the domain flu-
ents and the domain actions, respectively.
3.1 Usage Policy Language
The language for the specification of the usage control
policy of the target domain includes permissions, pro-
hibitions, action obligations and state obligations. We
first clarify concepts underlying usage control to pro-
vide justification for elements of the policy language.
Usage Session. Usage controls specify constraints
that should be satisfied before, while and after a usage
session. Figure 1 shows the phases of a typical usage
control session (explainedbelow)and actions relevant
to each. Actions in a usage session can be classified
into user actions (the actions tryaccess and endaccess
in Figure 1) and controller actions (the actions deny-
access, permitaccess, revokeaccess and precontrol in
Figure 1).
Admission Control is the first control phase in a usage
session; it checks whether the requested access is au-
thorized by the policy. Three possible decisions may
be reached after policy evaluation: (1) access should
be denied, (2) access should be allowed or (3) ac-
cess should be allowed provided the satisfaction of
some pre-access requirements, e.g., to accept the us-
age terms of the application.
Pre-usage Control starts after admission control if
the requested access further requires the satisfaction
of some pre-access requirements. During this phase,
the fulfilment of the pre-access requirements is mon-
itored: if they are successfully fulfilled, access is
granted, otherwise access is denied.
Ongoing-usage Control starts after the satisfaction
of the pre-access requirements. During this phase,
ongoing-access requirements are monitored: access
continues as long as the requirements are satisfied,
otherwise access is revoked. This phase ends when
either access is revoked or when the action terminat-
ing the usage session is taken.
Usage Controls. The three decision factors of us-
age control are authorizations, obligations and condi-
tions (Sandhu and Park, 2004). They are evaluated
before and while access. Our usage policy language
aims at covering the expression of these elements. A
usage control policy P
U
for an action description D is
therefore a set of the following propositions:
PERMITTED A
h
IF F
b
(1)
PROHIBITED A
h
IF F
b
(2)
USAGE [A
s
− A
e
]{ [ OBL ]
∗
} (3)
where F
b
is a fluent formula composed using the do-
main fluents and A
h
, A
s
and A
e
are domain actions.
An authorization rule of the form (1) ((2)) specifies
that the execution of A
h
is allowed (denied) if the flu-
ent formula F
b
holds. A usage rule (3) states that a
usage session is initiated by the domain action A
s
and
terminated by A
e
. A
s
is called the start action of the
usage session and A
e
is called the end action of the
usage session. The usage controls applicable for a
usage session [A
s
, A
e
] are the set of obligations OBL.
These obligations can define either a pre-obligation or
an ongoing-obligation requirement. Pre- and ongoing
obligation requirements can be either action or state
obligations. Obligation are specified in the language
using propositions having one of the following forms:
PRE
d
a
A
h
IF F
b
action pre-obligation (4)
PRE
m
F
h
IF F
b
state pre-obligation (5)
ON
d
a
A
h
IF F
b
ongoing action obligation (6)
ON
m
F
h
IF F
b
ongoing state obligation (7)
where A
h
is a domain action, F
h
and F
b
are fluent for-
mulas and d is a positive integer representing the obli-
gation deadline. In a rule, F
h
and A
h
are called the
head and F
b
the body of the rule respectively. We im-
pose a restriction that is that any domain action A in D
can start only one usage session, i.e., there may be at
most one usage rule (3) with A as its start action. Oth-
erwise, it would be unclear which set of usage con-
trols applies for usage sessions initiated by A. Also
deadlines are not intended to represent real temporal
deadlines but to specify a relative temporal ordering
between obligations. Therefore, a limit is imposed on
the maximum deadline value. However, this is gen-
erally sufficient to correctly model the target domain
by ensuring a timely violation of obligations. The
management of obligations and their deadlines is ex-
plained in Section 4.3.
The following rules specify a usage control pol-
icy for the application iX: a user is allowed to play a
movie if he is not blacklisted. The action play starts a
usage session that requires the fulfilment of a condi-
tional pre-obligation to accept the usage terms within
two minutes (unless they have been already accepted)
and an unconditional obligation to pay for watching
the movie within three minutes. The usage policy also
specifies a conditional ongoing obligation specifying
that the user has to keep the ad window open during
the session (unless he is a privileged user). The usage
session is ended when the action stop is taken.
PERMITTED play IF ¬user
role = blacklisted
USAGE [play− stop]{
PRE
2
a
accept
terms IF ¬terms accepted
DynamicAnalysisofUsageControlPolicies
91

Admission
Control
Pre
Control
Ongoing
Control
tryaccess
precontrol
permitaccess
permitaccessdenyaccess
denyaccess
revokeaccess
endaccess
Figure 1: Usage Control Session.
PRE
3
a
pay IF true
ON
m
ad
window IF ¬user role = privileged }
In the following, we use Γ(X) to denote the body of
a rule whose head is X. It will be also called the acti-
vation condition of the corresponding rule. The set of
pre-obligations and ongoing obligations of some us-
age session [A
s
, A
e
] will be denoted as p(A
s
, A
e
) and
o(A
s
, A
e
), respectively.
4 USAGE-CONTROLED
DESCRIPTIONS
To study the effects of the enforcement of a usage
policy P
U
on the target domain, the action descrip-
tion of the target domain D is extended into a usage-
controled action description D
P
U
, modeling the tar-
get domain D after the enforcement of the policy
P
U
in it. The extended action description is con-
structed as follows: First, every domain action A in
D is replaced by two actions in D
P
U
: a tryaccess(A)
action (to represent a request to execute A) and a
permitaccess(A) action (to represent the execution of
A). The tryaccess(A) action has the same executabil-
ity conditions of A, and the execution of the ac-
tion permitaccess(A) has the same effects of A. The
tryaccess(A) actions are called user actions in the fol-
lowing discussions.
A number of policy fluents and policy actions are
also added to the signature to model usage policy en-
forcement. These elements are necessary to reason
about the effects of the application of P
U
on the do-
main D. In particular, policy fluents are used to de-
scribe the policy state, e.g., they describe the state of
usage sessions and usage controls in the system. On
the other hand, the policy actions define the opera-
tions used to update and manage the usage control
policy state. The effects of policy actions on policy
fluents is formally specified using causal laws, clari-
fying the update of the usage control policy after the
execution of policy management actions. The policy
management causal laws are called the policy man-
agement rules. The action description extended with
the aforementioned actions, fluents and causal laws
define the usage-controlled action description D
P
U
.
Table 4: Fluent and Action Constants.
Fluent Constant Domain
session(play-stop) {initial, requesting, waiting,
accessing, ended, denied, revoked}
session(stop-none) {initial, requesting, waiting,
accessing, ended, denied, revoked}
Action Constant Description
denyaccess(play) deny access
permitaccess(play) start ongoing-usage controls
precontrol(play) activate pre-usage controls
revokeaccess(play) revoke access
The sets of policy fluents and actions of D
P
U
are de-
noted by F
P
and A
P
, respectively.
4.1 Extending the Language Signature
Controller Actions and Usage Sessions: Figure 2
shows an abstract representation of a usage ses-
sion. A usage session may be in one of the
states {idle, requesting, waiting, accessing, revoked,
denied, ended}. Change in the state of a us-
age session is caused by either a user action A ∈
{tryaccess, endaccess}, i.e. actions that start or end
a usage session; or a session management action
A ∈ {permitaccess, precontrol, denyaccess, revokeac-
cess}, i.e. actions that update the usage session state.
Every domain action A in D is associated with a
usage session, represented using a policy fluent.When
A is the start action of a usage rule (6) in the speci-
fied usage control policy, e.g., the action play, then
this policy fluent has the form session(A-A
′
), where
A
′
is the action that ends the usage session, e.g., stop.
When A is not the start action of any usage rule (6),
e.g., the action stop, then the policy fluent has the
form session(A,none). A policy action is also added
for every session management action appearing in
Figure 2. Table 4 shows the action and fluent con-
stants added for the domain actions play and stop.
Authorization Fluents: Authorization rules of the
form 4 or 5 in the policy are represented using stati-
cally determined fluents that hold only when their ac-
SECRYPT2014-InternationalConferenceonSecurityandCryptography
92

idle requesting waiting accessing
precontrol
tryaccess
permitaccess
permitaccess
(No usage
control)
revokeaccess
denied revoked
endaccess
ended
denyaccessdenyaccess
Figure 2: Usage Control State Model
tivation conditions hold:
perm(A
h
) IFF Γ(A
h
) proh(A
h
) IFF Γ(A
h
)
For example, the permission to execute the action
play in Example 1 is represented as follows:
perm(play) IFF ¬user
role = blacklisted
Obligation Fluents: Every action obligation in the
usage policy P
U
is denoted using a separate policy
fluent of the form obl
d
a
(A)
1
. The domain of this flu-
ent is {inactive, active(X), violated, fulfilled} where
X ∈ {1,...,d}, representing the possible states of the
obligation. When the obligation is a state obligation,
its policy fluent is of the form obl
s
(F) and its do-
main includes the values {inactive, active}. Violated
and fulfilled state obligations are represented using
two statically determined boolean fluents of the form
obl
s
(F)=fulfilled and obl
s
(F)=violated, respectively.
Action and state obligations are represented differ-
ently since the fulfilment/violation of a state obliga-
tion is defined in terms of state conditions whereas the
fulfilment/violation conditions of action obligations is
caused by action occurrences. This will be clarified
in Section 4.3. Table 5 shows the fluents used corre-
sponding to obligations in Example 1.
Table 5: Obligation Fluent Constants.
Fluent Constant Domain
obl
2
a
(accept terms) {inactive, active(2), active(1),
fulfilled, violated}
obl
3
a
(pay) {inactive, active(3), active(2),
active(1), fulfilled, violated}
obl
s
(ad window) {inactive, active}
obl
s
(ad window)=violated boolean
obl
s
(ad window)=fulfilled boolean
Pre-usage and Ongoing Usage Controls: To link pre-
obligationsand ongoingobligations to usage sessions,
we use a boolean statically determined fluent that
holds only when the activation conditions of the obli-
gation hold. This fluent is defined for each obligation
1
We slightly abuse the notation and use subscripts and
superscripts when writing obligation fluents for clarity.
in P
U
according to the obligation type as follows:
preobl([A
s
, A
e
], A
h
) IFF Γ(A
h
) action pre-obligation
preobl([A
s
, A
e
], F
h
) IFF Γ(F
h
) state pre-obligation
onobl([A
s
, A
e
], A
h
) IFF Γ(A
h
) action on-obligation
onobl([A
s
, A
e
], F
h
) IFF Γ(F
b
) state on-obligation
Obligations in Example 1 are linked to the usage ses-
sion [play,stop] as follows:
preobl([play, stop], pay) IFF ⊤
preobl([play, stop], accept
terms) IFF ¬terms accepted
onobl([play, stop], ad
window) IFF
¬user role = privileged
4.2 Usage Control Management
Usage policy management rules are causal laws, in-
cluded into the usage controlled action description
D
P
U
. In this section, the notation obl(X) is used to rep-
resent both an action obligation obl
d
a
(X) and a state
obligation obl
s
(X) when their management rules are
specified similarly. Figure 3 illustrates the main pol-
icy management operations discussed in this section.
Admission Control: It starts after an access request,
i.e., when a tryaccess(A) action occurs, and consists
of an evaluation of the policy: the request is denied
by taking the action denyaccess if the action is not au-
thorized and, consequently, the usage session state be-
comes denied. Otherwise, if the action does not start a
usage session, then access is immediately granted (the
action permitaccess(A) is taken) and the session state
returns to idle. If the action starts a usage session,
then the action precontrol is initiated to start the pre-
usage control phase, making the usage session wait-
ing. The following causal laws define this policy en-
forcement paradigm, illustrated in Figure 3. Note that
Figure 3 does not show the effects of the policy man-
agement actions denyaccess(A) and revokeaccess(A)
due to space limitation.
DynamicAnalysisofUsageControlPolicies
93

tryaccess(A) CAUSES session(A,A)=requesting
IF session(A,
A)=idle
denyaccess(A) IF session(A,
A)=requesting&
¬allowed(A)
denyaccess(A) CAUSES session(A,A)=denied
precontrol(A,A’) IF session(A,A’)=requesting&
allowed(A)
precontrol(A) CAUSES session(A,A’)=waiting
IF session(A,A’)=requesting
permitaccess(A)IF session(A,none)=requesting&
allowed(A)
permitaccess(A) CAUSES session(A,none)=idle
IF session(A,none)=requesting
where A and A
′
are variables ranging over the set of
domain actions,
A is a variable over the set A∪{none}
and allowed(A) is a statically determined fluent defin-
ing the admission control policy evaluation strategy.
The following strategies may be considered:
allowed(A) IFF perm(A) closed-policy
allowed(A) IFF ¬proh(A) open-policy
allowed(A) IFF perm(A) & ¬proh(H) precedence
The closed-policy (open-policy) strategy states that an
action is allowed only if there is an explicit permission
(prohibition) authorizing (forbidding) it. The prece-
dence strategy specifies that an action is authorized
only if it is explicitly permitted and not prohibited.
Pre-usage Controls Activation: The start of the pre-
usage control phase, i.e., the execution of the ac-
tion precontrol(A), activates the pre-obligations de-
fined for the usage session that is started by A. Action
and state obligations are activated as follows:
precontrol(A,A’)CAUSES obl
s
(P)=active IF preobl([A,
A’],P)& obl
s
(P)=inactive where P ∈ p(A,A’)
precontrol(A,A’) CAUSES obl
d
a
(A
h
)=active(d) IF preo-
bl([A, A
′
], A
h
)&
d
a
(A
h
)=inactive where A
h
∈ p(A,A’)
The previous rules specify that precontrol(A) activates
a pre-obligation X ∈ p(A, A
′
) if X is required, i.e.,
preobl([A, A
′
], X) holds and the obligation is inactive.
Pre-usage Controls Monitoring: Activated pre-
obligations are monitored in the state waiting as fol-
lows: if any of the pre-obligations is violated, then
denyaccess(A) is initiated to end the usage session.
Access is granted whenever all the required pre-
obligations are satisfied. This occurs when all pre-
obligations are in either the fulfilled or inactive state.
This is specified using the following rules:
denyaccess(A) IF session(A, A
′
) = waiting &
_
P∈p(A,A
′
)
obl(P) = violated
permitaccess(H) IF session(A, A
′
) = waiting &
^
P∈p(A,A
′
)
(obl(P) = inactive ∨ obl(P) = fulfilled)
Pre-usage Control Satisfaction/Violation: The satis-
faction of the pre-usage controls starts the ongoing-
usage control phase, i.e. session state becomes ac-
cessing. Active pre-obligations are canceled, i.e. their
state becomes inactive after the end of the pre-usage
control phase as follows:
permitaccess(A) CAUSES session(A,A’)=accessing
IF session(A,A’)=waiting
denyaccess(A)CAUSES obl(P)=inactive
IF ¬obl(P)=inactive
permitaccess(A) CAUSES obl(P)=inactive
IF ¬obl(P)=inactive where P ∈ p(A, A
′
)
Ongoing Usage Controls Activation: The permitac-
cess(A) action starts the ongoing-usage control phase
and activates the session’s ongoing obligations O ∈
o(A, A
′
) as follows:
permitaccess(A)CAUSES obl
s
(O)=active
IF onobl([A,A’],O) & obl
s
(O)=inactive
permitaccess(A)CAUSES obl
d
a
(O)=active(d)
IF onobl([A,A’],O) &obl
d
a
(O) = inactive
Ongoing Usage Controls Monitoring: In state
accessing, ongoing obligations are monitored. If any
of the ongoing obligations is violated, then the usage
session is revoked.
revokeaccess(A) IF session(A,A’)=accessing &
_
O∈o(A,A’)
obl(O)=violated
Ending of the Usage Session: The usage session is
ended if either access is revoked or the end action
of the usage session is executed. In the former case,
the usage session state becomes revoked. In the lat-
ter case, the usage session state becomes ended. Af-
ter the end of a usage session, all ongoing-obligations
SECRYPT2014-InternationalConferenceonSecurityandCryptography
94

revokeaccess(a)
permitaccess(a')
deny(a)
permitaccess(a)
precontrol(a)
premitaccess(a)
(Denial)
session(a,a')=waiting
∃P.obl(P)=violated
(Access)
session(a,a')=waiting
∀P.( obl(P)=inactive
∨ obl(P)=fulfilled)
preobl([a,a'],P)
obl(P)=inactive
precontrol(a)
obl(P)=active
session(a,a')=
requesting
precontrol(a)
session(a,a')=
waiting
(Session State Update)
(Pre-obligation Activation)
(Revocation)
session(a,a')=accessing
∃O. obl(O)=violated
(End)
session(a,a')=accessing
onobl([a,a'],O)
obl(O)=inactive
perrmitaccess(a)
obl(O)=active
session(a,a')=
waiting
perrmitaccess(a)
session(a,a')=
accessing
(Session State Update)
(Ongoing-obligation Activation)
session(a,a')
=requesting
allowed(a)
tryaccess(a)
session(a,ā)=
requesting
¬allowed(a)
session(a,n)
=requesting
allowed(a)
session(a,ā)=
idle
session(a,ā)=
requesting
(Provisional Access) (Denial) (Access)
(Access Request)
(Admission
Control)
(Pre-Usage
Control)
(Ongoing-Usage
Control)
denyaccess(a)
Figure 3: Usage Control Enforcement.
O ∈ o(A, A
′
) are canceled.
revokeaccess(A) CAUSES session(A,A’)=revoked
IF session(A,A’)=accessing
revokeaccess(A) CAUSES obl(O)=inactive
IF ¬obl(O)=inactive
permitaccess(A’) CAUSES session(A,A’)=ended
IF session(A,A’)=accessing
permitaccess(A’) CAUSES obl(O)=inactive
IF ¬obl(O)=inactive
4.3 Obligation Management
Usage controls are either action or state obligations.
This section formalizes the violation/fulfilment con-
ditions of obligations and the update of their state.
State Obligation Fulfilment/Violation: State obli-
gations are fulfilled (violated) if they are active and
their required state conditions hold (don’t hold). The
fulfilment and violation of a state obligation of the
form (8) or (10) is defined in terms of the fluents
obl(F
h
)=violated and obl(F
h
)=fulfilled as follows:
obl
s
(F
h
)=fulfilled IFF obl
s
(F
h
)=active & F
h
obl
s
(F
h
)=violated IFF obl
s
(F
h
)=active & ¬F
h
The following rules define the fulfilment and violation
of the ongoing obligations in Example 1.
obl
s
(ad
window)=fulfilled
IF obl
s
(ad window)=active &ad window
obl
s
(ad
window)=violated
IF obl
s
(ad window)=active &¬ad window
State Obligation Cancellation: Obligations are
contextual. Therefore, an obligation is canceled when
its conditions no longer hold. This is specified as fol-
lows for state obligations of the form (8) or (10):
obl
s
(F
h
)=inactive IF ¬Γ(F
h
)
For example, the followingrule specifies when the on-
going obligation in Example 1 is canceled.
obl
s
(ad window)=inactive IF ¬user role=privileged
Action Obligation Fulfilment: An active action
obligation of the form (7) and (9) is fulfilled after the
execution of its action as follows:
obl
d
a
(A
h
)=fulfilled AFTER obl
a
(A
h
)=active(N)&
permitaccess(A
h
) where N ∈ {1, . . . , d}
The fulfilment of action obligations in Example 1 is
defined as follows:
obl
2
a
(accept
terms)=fulfilled IF true
AFTER obl
2
a
(accept
terms)=active(N
1
)&
permitaccess(accept terms) where N
1
∈ {1, 2}
obl
3
a
(pay)=fulfilled IF user
role=privileged
AFTER obl
3
a
(pay)=active(N
2
)&
permitaccess(pay)whereN
2
∈ {1, 2, 3}
Action Obligation Cancellation: An action obli-
gation is canceled if its conditions do not hold and the
obligation was not yet fulfilled.
obl
d
a
(A
h
)=inactive IF ¬Γ(A
h
)
AFTER ¬permitaccess(A
h
)
The cancellation of the action obligations of Exam-
ple 1 is defined as follows:
obl
2
a
(accept
terms)=inactive IF ¬true
AFTER ¬permitaccess(accept terms)
obl
3
a
(pay) = inactive IF user
role = privileged
AFTER ¬permitaccess(pay)
DynamicAnalysisofUsageControlPolicies
95

Note that ¬¬ f is equated with f and that the obliga-
tion to accept terms can not be canceled since its can-
cellation conditions can never be true, namely ¬true.
Action Obligation Violation: An active action
obligation is violated after the elapse of the period
specified in its deadline. An action obligation can
be in different active states according to the time that
is left before its deadline elapses. In particular, an
obligation Obl
d
a
(A) is in the state active(d) when it
is activated, as presented in Section 4.2. The pas-
sage of time is simulated using an exogenous action
clock, whose occurrence updates an obligation in the
state active(n) to the state active(n
′
) by decreasing
the value of n by one, i.e., n
′
= n − 1. The obliga-
tion is violated after an occurrence of the action clock
when the state of the obligation is active(1) and the
obligation has not been canceled nor fulfilled. This is
specified using the following rules for action obliga-
tions of the form (7) or (9):
obl
d
a
(A
h
)=violated IF Γ(A
h
) AFTER obl
d
a
(A
h
)=
active(1)&clock&¬permitaccess(A
h
)
clock CAUSES obl
d
a
(A
h
)=active(d’) IF obl
d
a
(A
h
)=
active(d) where d > 1, d
′
is d − 1
State Update. The update of state as a result of access
enables, for example, to change a subject’s attributes
after access revocation (Sandhu and Park, 2004). In
our framework, state update is specified as post ef-
fects of the usage session management actions. For
example, access revocation may cause the role of the
user to become blacklisted as follows:
revoke(play) CAUSES user
role=blacklisted
Similarly, the state can be updated after access accep-
tance and denial using the actions permitaccess(A)
and denyaccess(A) respectively. Note that it is simi-
larly possible to activate obligations after the execu-
tion of usage session management actions. This al-
lows specification of post-obligations in our frame-
work, i.e. requirements that should be satisfied after
the end or revocation of access. The support of post-
obligations is however not discussed in this paper due
to space limitations.
Multiple Sessions. In Figure 2, the states denied, re-
voked and ended are terminal states. To support mul-
tiple usage sessions, the session state is reset to the
state idle when a terminal state is reached by initiat-
ing the policy management action reset
session:
reset
session(A,A’) IF session(A,A’)=denied∨
session(A,A’)=ended ∨ session(A,A’)=revoked
reset
session(A,A’) CAUSES session(A,A’)=idle
5 POLICY ANALYSIS
The use of C+ enables the use of model check-
ing techniques for the verification of properties of
labeled transition systems described by action lan-
guage descriptions. This section identifies and for-
malizes some important usage control policy prop-
erties using Action-based Computational Tree Logic
(ACTL) (Bouali et al., 1994), enabling their verifica-
tion using standard ACTL-model checkers. The au-
tomated verification of usage control policies ensures
the correctness of usage control policies before their
deployment. For example, it enables to ensure re-
source availability, i.e. that the specified security con-
trols do not make system resources inaccessible. It
also ensures that security controls cannot be circum-
vented, i.e. that resources can only be accessed after
the satisfaction of the specified security controls. The
complexity of model checking algorithms for ACTL
formulas is linear in the state space of the system
model and the formula.
Labeled Transition System of an Action Descrip-
tion. An action description D defines a labeled tran-
sition system TS = hS, L, →i as described in Sec-
tion 2.3:
• If q ∈ S is a state and A ∈ L is an action,
R
A
(q) denotes the set of actions that the state
q can take, i.e., the set {q
′
|there exists α ∈
A such that (q, α, q
′
) ∈→}. R(q) denotes R
L
(q).
• A path in TS is a finite or infinite sequence
q
1
, q
2
, . . . such that every q
i+1
∈ R(q
i
);
• We denote the set of paths starting from a state q
by Π(q), and use σ, σ
′
, . . . to range over paths;
• A path is maximal if it is infinite, or finite and its
last state q
′
has no successor states, i.e., R(q
′
) =
/
0;
• If σ is infinite then |σ| = ω; if σ = q
1
, q
2
, . . . , q
n
,
then |σ| = n − 1. Moreover, if |σ| ≥ i − 1, then
σ(i) denotes the i
th
state in the sequence.
Action Formulas. Let b ∈ L. The language L(L) of
action formulas on L is defined as follows:
X ::= ⊤ | b | ¬X | X ∨ X
where b ranges over L. The satisfaction relation |= for
action formulas is defined as:
a |= ⊤ always
a |= b iff a = b
a |= ¬X iff not a |= X
a |= X ∨ X iff a |= X or a |= X
′
Let X be an action formula, the set of actions satisfy-
ing X is characterized by the function k : L(L) → 2
L
SECRYPT2014-InternationalConferenceonSecurityandCryptography
96

as follows:
k(⊤) = L
k(b) = {b}
k(¬X ) = L\ k(X )
k(X ∨ X
′
) = k(X ) ∪ k(X
′
)
ACTL Syntax. ACTL is a branching-time temporal
logic of state formulas (denoted by φ), in which a path
quantifier prefixes an arbitrary path formula (denoted
by π). The syntax of ACTL formulas is given by the
following grammar
2
:
φ ::= ⊤ | φ ∧ φ | ¬φ | Eπ | Aπ
π ::= X
X
φ | φ
X
Uφ | φ
X
U
X
′
φ
where X and X
′
range over action formulas, E and A
are the existential and universal path quantifiers, re-
spectively. X and U are the next and until operators,
respectively. The following is a set of common abbre-
viations of other modalities: the eventuality operators
EFφ ↔ E(⊤
⊤
U
X
φ) and AFφ ↔ A(⊤
⊤
U
X
φ); the al-
ways operators EGφ ↔ ¬AF¬φ and AGφ ↔ ¬EF¬φ.
ACTL Semantics. The satisfaction relation for
ACTL formulas is defined as follows:
s |= ⊤ always;
s |= φ ∧ φ
′
iff s |= φ and s |= φ
′
;
s |= ¬φ iff not s |= φ;
s |= Eπ iff there exists a path σ ∈ Π(s)
such that σ |= π;
s |= Aπ iff for all maximal paths σ ∈ Π(s),
σ |= π;
s |= X
X
φ iff |σ| ≥ 1 and σ(2) ∈ R
k(X )
(σ(1))
and σ(2) |= φ;
s |= φ
X
Uφ
′
iff there exists i ≥ 1 such that σ(i) |= φ
′
and for all i ≤ j ≤ i− 1, σ( j) |= φ
and σ( j +1) ∈ R
k(X )
(σ( j));
s |= φ
X
U
X
′
φ
′
iff there exists i ≥ 2 such that σ(i) |= φ
′
σ(i− 1) |= φ, σ(i) ∈ R
k(X
′
)
(σ(i− 1))
and for all i ≤ j ≤ i− 2,
σ( j+ 1) ∈ R
k(X )
(σ( j)).
Analysis. Table 6 identifies and summarizes some
important usage control policy properties in the form
of ACTL formulas, enabling the automation of their
formal verification.
System Accountability: A system is said to be ac-
countable if obligations assigned by the system can
2
Note that we omit X
τ
φ from its original syntax descrip-
tion, as actions τ do not play a role in our formulation.
be fulfilled (Irwin et al., 2006). In our work, two fac-
tors impact system accountability, namely authoriza-
tion policies and action executability conditions.
• An action obligation can only be fulfilled if it is
allowed by the specified authorization policies.
An obligation action can be allowed throughout
or only partially during the activation period of
the obligation. These properties can be specified
using the ACTL formulas (1) and (2) in Table 6
respectively for the action A
h
of a pre-obligation
of the form (7) in some usage rule [A, A
′
] in the
usage control policy.
• Action Executability: An action A is executable at
a state if the action tryaccess(A) can be taken in
this state, i.e., that the action preconditions hold.
Similarly to action allowance, the action of an
obligation may be executable throughout or only
partially during the activation period of the obli-
gation. Formulas (3) and (4) in Table 6 enable the
verification of these properties for the action A
h
of a pre-obligation of the form (7) in a usage rule
[A, A
′
] in the policy.
A system is strongly accountable only if the ac-
tion of every obligation in the policy is both allowed
and executable during the obligation lifetime. It is
weakly accountable if every obligation action is both
allowed and executable sometime during the obliga-
tion lifetime. The formulas (5) and (6) in Table 6 de-
fine when the system is accountable with respect to
the action A
h
of a pre-obligation of the form (7) in a
usage rule [A, A
′
] in the usage control policy. Global
system accountability is checked by verifying these
properties for every pre-obligation action and every
ongoing-obligation action in the usage control policy.
We do not present the formulas for verifying global
accountability nor formulas correspondingto ongoing
obligations due to space limitation.
State Obligation Satisfiability and Violation: It is
sometimes necessary to verify that a state obligation
is satisfied at the moment of its activation and that
the obligation may later be violated. For example,
the activation of an ongoing obligation to keep an ad
window open may be unreasonable if the ad window
is not open at the moment the obligation is activated;
also there should a path where the obligation is vio-
lated after its activation; otherwise the obligation is
unnecessary (void). The ACTL formulas (7) and (8)
respectively in Table 6 check whether the condition
F
h
required by an ongoing state obligation of the form
(10), in a usage rule [A, A
′
] in the usage control pol-
icy, is satisfied after the activation of the obligation
and that this condition may later become false during
the obligation lifetime respectively.
DynamicAnalysisofUsageControlPolicies
97

Table 6: ACTL Formulas for Verification of Usage Control Policy Properties.
Property ACTL Formula
1 Pre-Obl. Action Fully Allowed AG((session(A,A’)=waiting∧ obl
d
a
(A
h
)=active) → allowed(A
h
))
2 Pre-Obl. Action Partially Allowed AG ((session(A,A’)=waiting∧ obl
d
a
(A
h
)=active) →
E(session(A, A
′
) = waiting
⊤
U allowed(A
h
))
3 Pre-Obl. Action Fully Executable AG ((session(A,A’)=waiting∧obl
d
a
(A
h
)=active) → EX
tryaccess(A
h
)
⊤)
4 Pre-Obl. Action Partially Executable AG ((session(A,A’)=waiting∧ obl
d
a
(A
h
)=active) →
E(session(A, A
′
) = waiting
⊤
U EX
tryaccess(A
h
)
⊤))
5 System Strong Accountability AG ((session(A,A’)=waiting∧ obl
d
a
(A
h
)=active) →
(allowed(A
h
) ∧ EX
tryaccess(A
h
)
⊤))
6 System Weak Accountability AG ((session(A,A’)=waiting∧ obl
d
a
(A
h
)=active) →
E(session(A, A
′
) = waiting
⊤
U (allowed(A
h
) ∧ EX
tryaccess(A
h
)
⊤)))
7 State On-Obl. Satisfaction AX
permitaccess(A)
(F
h
)
8 State On-Obl. Violation AG ((session(A,A’)=accessing∧ obl
s
(F
h
)=active) →
E(session(A, A
′
) = accessing
⊤
U ¬F
h
))
We have identified and formalized other important
usage control specific properties such as consistency
of controls, usage session termination and access de-
nial and revocation. They are however not discussed
in this paper due to space limitations.
6 RELATED WORK
A classification of policy analysis techniques can be
made according to the type of security policies con-
sidered, e.g., access control, obligations or usage con-
trol policies, and the type of analysis targeted, i.e.,
static or dynamic. The static analysis of access con-
trol policies is by far the most studied. An overview
of access control policy conflicts and their resolution
techniques is presented in (Lupu and Sloman, 1999;
Samarati and de Vimercati, 2001).
The dynamic analysis of access control policies
is supported in (Becker and Nanz, 2007), which in-
troduces a non-monotonic extension of datalog al-
lowing specification of action effects in access con-
trol policy rules. A goal-oriented algorithm is used
to find minimal action sequences that lead to a spec-
ified target authorization state. In (Li and Tripuni-
tara, 2006), the RBAC policy scheme (Ferraiolo et al.,
1995; Sandhu et al., 1996) is modeled as a state-
transition system, where changes occur via adminis-
trative operations. Security analysis techniques an-
swer questions such as whether an undesirable state is
reachable and whether every reachable state satisfies
some safety or availability properties. A framework
for the dynamic analysis of security policies that in-
clude authorizations and obligations is presented in
(Craven et al., 2009). In this framework, domains
regulated by policies are formalized using the event
calculus (Shanahan, 1999), enabling formal analysis
of the target domain and its security policy. A meta-
model for the analysis of authorization systems with
obligations is introduced in (Irwin et al., 2006). This
paper focuses on the study of the system accountabil-
ity problem, i.e., ensuring that assigned obligations
will be fulfilled if system subjects are diligent. The
aforementioned works do not consider usage control
systems where authorizations, obligations and usage
sessions interact.
UCON
ABC
(Sandhu and Park, 2004) is formal-
ized in (Zhang et al., 2005) using Lamport’s Tempo-
ral Logic of Actions (TLA). The safety analysis of
UCON
A
positive authorization policies is presented
in (Zhang et al., 2006). This work is generalized in
(Ranise and Armando, 2012). In comparison, we sup-
port analysis of usage policies that include authoriza-
tions, prohibitions and obligations. The model check-
ing of policies specified using the Obligation Speci-
fication Language (OSL) (Hilty et al., 2007) is stud-
ied in (Pretschner et al., 2009). OSL is a temporal
logic with explicit operators for cardinality and per-
missions whose semantics is defined over traces of
parameterized events. In comparison, our work en-
ables the formal description of the target domain and
the automated verification of properties of usage con-
trol policies in their target domain. Furthermore, our
work formalizes the management of usage controls
and usage sessions, concepts that are not considered
in (Pretschner et al., 2009). The XACML language
and architecture are extended in (Li et al., 2012) to
SECRYPT2014-InternationalConferenceonSecurityandCryptography
98

add support for access control policies with obliga-
tions and a framework for the specification and en-
forcement of data handling policies is presented in
(Ardagna et al., 2008). These works do not address
the dynamic analysis of usage control policies.
7 CONCLUSION
This paper introduces an approach for the formal
analysis of usage control policies and study of their
application on target domains. Thus, our work is a
first step in providing policy officers a valuable means
to formally verify the correctness of specified poli-
cies before their deployment. Furthermore, we have
identified and formalized several usage control spe-
cific properties and automated their verification.
This work can be extended to support structured
policies with pre-defined sets of basic entities (El-
rakaiby et al., 2012). We also intend to investigate the
use ofC+
timed
(Craven and Sergot, 2005) to provide a
more elegant representation of delays and deadlines,
and to design heuristics for our approach to make
model checking scale better to real-world scenarios.
REFERENCES
CCalc. http://www.cs.utexas.edu/∼tag/cc/.
iCCalc. http://www.doc.ic.ac.uk/∼rac101/iccalc/.
Ardagna, C. A., Cremonini, M., De Capitani di Vimercati,
S., and Samarati, P. (2008). A privacy-aware access
control system. JCS, 16(4):369–397.
Armando, A., Giunchiglia, E., Maratea, M., and Ponta, S. E.
(2012). An action-based approach to the formal spec-
ification and automatic analysis of business processes
under authorization constraints. Journal of Computer
and System Sciences, 78(1):119–141.
Armando, A., Giunchiglia, E., and Ponta, S. E. (2009). For-
mal specification and automatic analysis of business
processes under authorization constraints: An action-
based approach. In TrustBus, volume 5695 of LNCS,
pages 63–72. Springer.
Artikis, A. and Sergot, M. (2010). Executable specification
of open multi-agent systems. Logic Journal of IGPL,
18(1):31–65.
Artikis, A., Sergot, M. J., and Pitt, J. (2007). An executable
specification of a formal argumentation protocol. Ar-
tificial Intelligence, 171(10-15):776 – 804.
Babb, J. and Lee, J. (2013). Cplus2asp: Computing action
language c+ in answer set programming. Logic Pro-
gramming and Nonmonotonic Reasoning, page 122.
Becker, M. Y. and Nanz, S. (2007). A logic for state-
modifying authorization policies. In ESORICS, vol-
ume 4734 of LNCS, pages 203–218. Springer.
Bouali, A., Gnesi, S., and Larosa, S. (1994). The integration
project for the JACK environement. Bulletin of the
EATCS, 54:207–223.
Casolary, M. (2011). Representing the language of the
causal calculator in answer set programming. PhD
thesis, Arizona State University.
Craven, R., Lobo, J., Ma, J., Russo, A., Lupu, E., and Ban-
dara, A. (2009). Expressive policy analysis with en-
hanced system dynamicity. In ASIACCS, pages 239–
250. ACM.
Craven, R. and Sergot, M. (2005). Distant causation in C+.
Studia Logica, 79(1):73–96.
Dworschak, S., Grell, S., Nikiforova, V., Schaub, T., and
Selbig, J. (2008). Modeling biological networks by
action languages via answer set programming. Con-
straints, 13(1-2):21–65.
Elrakaiby, Y., Cuppens, F., and Cuppens-Boulahia, N.
(2012). Formal enforcement and management of obli-
gation policies. DKE, 71(1):127 – 147.
Ferraiolo, D., Cugini, J., and Kuhn, D. R. (1995). Role-
based access control (rbac): Features and motivations.
In ACSAC, pages 241–48. ACM.
Gebser, M., Grote, T., and Schaub, T. (2010). Coala: a
compiler from action languages to ASP. In Logics in
Artificial Intelligence, pages 360–364. Springer.
Gelfond, M. and Lifschitz, V. (1998). Action languages.
Electronic Transactions on AI, 3(16).
Giunchiglia, E., Lee, J., Lifschitz, V., McCain, N., Turner,
H., and Lifschitz, J. L. V. (2004). Nonmonotonic
causal theories. Artificial Intelligence, 153:49–104.
Hilty, M., Pretschner, A., Basin, D., Schaefer, C., and Wal-
ter, T. (2007). A policy language for distributed usage
control. In ESORICS, volume 4734 of LNCS, pages
531–546. Springer.
Irwin, K., Yu, T., and Winsborough, W. H. (2006). On the
modeling and analysis of obligations. In CCS, pages
134–143. ACM.
Li, N., Chen, H., and Bertino, E. (2012). On practical spec-
ification and enforcement of obligations. In Proceed-
ings of the Second ACM Conference on Data and Ap-
plication Security and Privacy, CODASPY ’12, pages
71–82, New York, NY, USA. ACM.
Li, N. and Tripunitara, M. V. (2006). Security analysis in
role-based access control. TISSEC, 9(4):391–420.
Lifschitz, V. (1999). Action languages, answer sets, and
planning. In The Logic Programming Paradigm,
pages 357–373. Springer.
Lupu, E. C. and Sloman, M. (1999). Conflicts in
policy-based distributed systems management. TSE,
25(6):852–869.
Pretschner, A., Ruesch, J., Schaefer, C., and Walter, T.
(2009). Formal analyses of usage control policies. In
ARES, pages 98–105. IEEE.
Ranise, S. and Armando, A. (2012). On the automated
analysis of safety in usage control: a new decidability
result. In NSS’12, pages 15–28, Berlin, Heidelberg.
Springer-Verlag.
Samarati, P. and de Vimercati, S. C. (2001). Access con-
trol: Policies, models, and mechanisms. In Founda-
DynamicAnalysisofUsageControlPolicies
99

tions of Security Analysis and Design, pages 137–196.
Springer.
Sandhu, R., Coyne, E. J., Feinstein, H. L., and Youman,
C. E. (1996). Role-based access control models. Com-
puter, 29(2):38–47.
Sandhu, R. and Park, J. (2004). The UCON ABC usage
control model. TISSEC, 7(1):128–174.
Sergot, M. (2004). An action language for modelling norms
and institutions. Technical Report 2004/8, Imperial
College London.
Shanahan, M. (1999). The event calculus explained. In Ar-
tificial Intelligence Today, pages 409–430. Springer.
Simon, R. T. and Zurko, M. E. (1997). Separation of duty
in role-based environments. In Proceedings of the
10th Computer Security Foundations Workshop, pages
183–194. IEEE.
Son, T. C., Pontelli, E., and Sakama, C. (2012). Formal-
izing commitments using action languages. In Pro-
ceedings of the 9th Conference on Declarative Agent
Languages and Technologies, volume 7169 of LNCS,
pages 67–83. Springer.
Zhang, X., Parisi-Presicce, F., Sandhu, R., and Park, J.
(2005). Formal model and policy specification of us-
age control. TISSEC, 8(4):351–387.
Zhang, X., Sandhu, R., and Parisi-Presicce, F. (2006).
Safety analysis of usage control authorization models.
In ASIACCS, pages 243–254. ACM.
APPENDIX
Action Description Example
Consider a signature that includes the two simple flu-
ent constants {p, q}, the statically determined fluent
constant r and the two actions {a1, a2}. The causal
laws below specify that the fluent q is inertial, i.e., its
value persists unless it is changed by an action occur-
rence; p is false by default but holds after the occur-
rence of a1; r is a statically determined fluent, i.e., its
truth depends on other fluents, that holds only when p
and q are true. The action a1 is exogenous, i.e., it may
occur at any state; a2, on the other hand, has to occur
in every transition from a state where r is true. The
execution of a2 causes p & ¬q to be true. Finally, we
specify that a void transition, i.e., the transition not
including a1 nor a2, is not executable.
q
q
p r
p
a1
a1 & a2
a2
a1
Figure 4: C+ Labeled Transition System Example.
Figure 4 shows the labeled transition system de-
scribed by this action description. Note that we con-
sider boolean fluent constants. A state in Figure 4 is
labeled with the set of fluents that are true in it.
INERTIAL q. DEFAULT ¬p.
DEFAULT ¬r. r IF p&q.
EXOGENOUS a1. DEFAULT ¬a2.
a2 IF r. p&¬q AFTER a2.
p AFTER a1. NONEXECUTABLE ¬a1&¬a2.
Running Example
The description of the iX movie player example con-
sists of a declaration of sorts and variables, fluent con-
stants, action constants and causal laws.
Sorts Fluents Actions
state(ready). fc(state). ac(turn on).
state(of f). domain(state,PS). ac(turn
of f ).
state(playing). fc(accept terms window). ac(play).
PS :: state(PS). fc(payment
window). ac(accept terms).
fc(ad window). ac(pay).
fc(terms accepted). ac(close ad).
fc(payment
accepted).
Causal Laws:
exogenous(A) : − ac(A).
inertial FC : − fc(FC).
CAUSED state = ready AFTER turn
on.
CAUSED accept terms window IF −terms accepted AFTER turn on.
CAUSED payment
window IF − payment accepted AFTER turn on.
CAUSED ad window AFTER turn on.
NONEXECUTABLE turn
on IF − state = off.
CAUSED state = playing AFTER play.
NONEXECUTABLE play IF − state = ready.
CAUSED state = off AFTER turn
off.
CAUSED − payment window AFTER turn off.
CAUSED − accept terms window AFTER turn off.
CAUSED − ad
window AFTER turn off.
NONEXECUTABLE turn off IF state = off.
CAUSED terms
accepted AFTER accept terms.
CAUSED − accept terms window AFTER accept terms.
NONEXECUTABLE accept terms IF − accept terms window.
CAUSED payment
accepted AFTER pay.
CAUSED − payment window AFTER pay.
NONEXECUTABLE pay IF − payment window.
CAUSED accept
terms window IF − terms accepted AFTER turn on.
CAUSED payment window IF − payment accepted AFTER turn on.
CAUSED − ad
window AFTER close ad.
NONEXECUTABLE close ad IF − ad window.
CAUSED f alse IF ad window&state = off.
CAUSED f alse IF payment
window&state = off.
CAUSED f alse IF accept terms window&state = off.
SECRYPT2014-InternationalConferenceonSecurityandCryptography
100