REWRITING-BASED SECURITY ENFORCEMENT OF

CONCURRENT SYSTEMS

A Formal Approach

Mahjoub Langar, Mohamed Mejri

LSFM Research Group, Computer Science Department, Laval University, Québec, Québec, Canada

Kamel Adi

LRSI Research Group, Computer Science Department, University of Quebec in Outaouais, Gatineau, Québec, Canada

Keywords:

Language based security, Runtime veriﬁcation, Concurrent systems, Process algebra, Formal veriﬁcation.

Abstract:

Program security enforcement is designed to ensure that a program respects a given security policy, which

generally speciﬁes the acceptable executions of that. In general, the enforcement is achieved by adding some

controls (tests) inside the target program or process. The major drawback of existing techniques is either their

lack of precision or their inefﬁciency, especially those dedicated for concurrent languages. This paper proposes

an efﬁcient algebraic and fully automatic approach for security program enforcement: given a concurrent

program P and a security policy φ, it automatically generates another program P

′

that satisﬁes φ and behaves

like P, except that it stops when P tries to violate the security policy φ.

1 INTRODUCTION

Until today, fully secure computer systems are still

a distant dream, mainly due to the subtleness and

the complexity of the problem. However, one of the

current and promising avenues of research for secur-

ing computer systems is the development of formal

frameworks for automatic enforcement of security

policies in programs. The goal of those approaches

is to ensure that a program respects a given secu-

rity policy which generally speciﬁes acceptable ex-

ecutions of the program. Security policies can be ex-

pressed in terms of access control problems, infor-

mation ﬂow, availability of resources, conﬁdential-

ity, etc. (Schneider, 2000) and the literature records

various techniques for enforcing security policies.

Thus, we mainly distinguish two principal classes:

static approaches including typing theory (Morrisett

et al., 1999), Proof Carrying Code (Necula, 1997),

and dynamic approaches including reference moni-

tors (Bauer et al., 2002; Ligatti et al., 2005; Martinell

and Matteucci, 2007), Java stack inspection (Erlings-

son and Schneider, 2000). Static analysis aims at en-

forcing properties before program execution. In dy-

namic analysis, however, the enforcement takes place

at runtime by intercepting critical events during the

program execution and halting the latter whenever

an action is attempting to violate the property be-

ing enforced. Recently several researchers have ex-

plored rewriting techniques (K. Hamlen and Schnei-

der, 2003) in order to gather advantages of both static

and dynamic methods. The idea consists in modifying

statically a program, so that the produced version re-

spects the requested requirements. The rewritten pro-

gram is generated from the original one by adding,

when necessary, some tests at some critical points to

obtain the desired behavior.

The literature record many formal works (Langar

et al., 2007; Langar and Mejri, 2005; Ligatti et al.,

2005; Mejri and Fujita, 2008; Ould-Slimane et al.,

2009) related to the rewriting of sequential programs,

however only few attempts have targeted concurrent

programs. This is due to the complexity added by the

parallelism operator. Even simple systems become

widely complicated when they are executed in par-

allel (Fokkink, 2000). However, the research commu-

nity knows that this challenge cannot be ignored for

a long time due to the urgent need for securing con-

current systems which are pervasive in every sphere

of human activity.

Langar M., Mejri M. and Adi K. (2010).

REWRITING-BASED SECURITY ENFORCEMENT OF CONCURRENT SYSTEMS - A Formal Approach.

In Proceedings of the International Conference on Security and Cryptography, pages 66-74

DOI: 10.5220/0002996100660074

 SciTePress

This paper proposes an algebraic and fully auto-

matic approach that could generate from a given pro-

gram and a security policy a new version of this pro-

gram that respects the requested security policy. More

precisely, this paper formally deﬁnes a syntactic op-

erator ⊗ that takes as input a process P and a security

policy φ and generates P

′

= P⊗ φ, a new process that

respects the following conditions:

• P

′

|∼ φ, i.e., P

′

"satisﬁes" the security policy φ.

• P

′

⊑ P, i.e., behaviours of P⊗ φ are subset of the

behaviours of P.

• ∀ Q : ((Q|∼ φ)∧(Q ⊑ P)) ⇒ Q ⊑ P

′

, i.e., all good

behaviours of P are in P⊗ φ.

P φ

⊗

′

= P⊗ φ

For the speciﬁcation of concurrent systems,

the suggested model uses an extended version of

ACP "Algebra for Communicating Process" (Baeten,

2005) denoted by ACP

. Moreover, the logic used for

the speciﬁcation of security policies is an extended

version of regular languages denoted by L

. The lan-

guage ACP

is deﬁned so that the enforcement oper-

ator is embedded in it. Furthermore, we deﬁne a set

of translation functions that allow to express our en-

forcement operator in terms of standard operator of

the process algebra ACP.

This paper is structured as follows. Section 2

presents a logic for specifying security policies. Sec-

tion 3 describes the syntax and the semantics of our

calculus used for specifying concurrent programs. In

Section 4 we present a formal framework based on the

introduced logic and process algebra for security poli-

cies enforcement on programs. Section 5 gives the

main theorem stating the correctness of our method.

Section 6 illustrates our method by An example. Fi-

nally, Section 7 provides concluding remarks.

2 SECURITY POLICY

SPECIFICATION

The purpose of this section is to deﬁne an adequate

logic for specifying the required security policies.

The important requested features of this logic are:

• the ability for specifying linear and temporal

properties. We are interested by properties that

could not be always statistically veriﬁed. There-

fore we expect that the program will be monitored

at runtime so that the violation of the requested

security property could be forbidden. To that end,

and since at runtime, we can see only one branch

of the program at a given time, then the expected

logic needs to be linear.

• suitable for safety properties. Safety properties

are the class of properties that can be dynamically

enforced. By safety we mean that something bad

will never happen during the execution of a pro-

gram.

• the ability for specifying ω-properties (inﬁnite

properties). An execution of a program could gen-

erate an inﬁnite sequence of actions and it is im-

portant to be able to monitor these behaviours.

For the above stated reasons and others that will

be clariﬁed later, the adopted logic is based on the

extended regular expressions (Sen and Rosu, 2003),

enhanced with the ability for specifying inﬁnite be-

haviours.

2.1 Syntax

The syntax of the proposed logic is presented by the

BNF grammar in Table 1, where a is an action in

a given ﬁnite set A , tt and f f denote the Boolean

constants and 1 denotes an empty sequence of ac-

tions. Furthermore, the logic contains standard propo-

sitional connectives (¬, ∧ and ∨) and a temporal op-

erator (.) denoting the operation sequencing. In the

sequel, we note L

the set of formulas that can be

speciﬁed in our logic.

For reasons that will be detailed below, we con-

sider a deterministic Kleene operator, i.e.: only for-

mulas ϕ

and ϕ

such that υ(ϕ

) ∩ υ(ϕ

) =

0 are al-

lowed in the form ϕ

∗

. Intuitively, υ(ϕ) is the set

of the ﬁrst actions allowed by the formula ϕ. For

example, υ(a.b.c) = {a}, υ((a ∨ b).c) = {a, b} and

υ(a.(b∨ c)) = {a}. More formally, the function υ is

deﬁned as follows:

υ : L

→ 2

υ(tt) = A

υ( f f) =

υ(1) =

υ(a) = {a}

υ(ϕ

∗

) = υ(ϕ

) ∪ υ(ϕ

)

υ(ϕ

∨ ϕ

) = υ(ϕ

) ∪ υ(ϕ

)

υ(ϕ

∧ ϕ

) = υ(ϕ

) ∪ υ(ϕ

)

υ(¬ϕ) = A \ υ(ϕ)

υ(ϕ

.ϕ

) = υ(ϕ

) ∪ (o(ϕ

) ⊖ υ(ϕ

))

REWRITING-BASED SECURITY ENFORCEMENT OF CONCURRENT SYSTEMS - A Formal Approach

where the function o(ϕ) allows to know whether the

language accepted by the formula contain the empty

sequence and it is deﬁned as follows :

o : L

→ {0, 1}

o(tt) = 1

o( f f) = 0

o(1) = 1

o(a) = 0

o(ϕ

.ϕ

) = o(ϕ

) × o(ϕ

)

o(ϕ

∨ ϕ

) = max(o(ϕ

), o(ϕ

))

o(ϕ

∗

) = o(ϕ

)

o(¬ϕ) = (o(ϕ) + 1) mod (2)

and the function ⊖ is deﬁned as follows:

⊖ : {0, 1} × 2

−→ 2

(0, S) 7→

(1, S) 7→ S

Table 1: Syntax of L

, ϕ

::= tt | f f | 1 | a | ϕ

.ϕ

| ϕ

∨ ϕ

∧ ϕ

| ¬ϕ | ϕ

∗

2.2 Semantics

Let T be the monoid (A , ., ε), the semantics of L

deﬁned by the function J K : L

→ T as shown in

Table 2. Intuitively, any trace respects the formula

true. No trace respects the formula false and only the

empty trace (ε) respects the formula 1. Only traces

that have preﬁxes respecting ϕ

and sufﬁxes respect-

ing ϕ

respect ϕ

.ϕ

. Only traces that respect ϕ

respect ϕ

∨ ϕ

. Only traces that respect both ϕ

and ϕ

respect ϕ

∧ϕ

. A trace respects ϕ

∗

if either

it respects ϕ

or it has a preﬁx that respects ϕ

and a

sufﬁx that respect ϕ

∗

. Finally, a trace respects ¬ϕ,

if it does not respect ϕ.

2.3 Shortcuts

For the sake of simplicity, we deﬁne the following

shortcuts where A is a subset of A , a ∈ A and "

is the abbreviation symbol:

a∈A

−A

= A − A

−a

= A − {a}

−

= A −

= ϕ

∗

f f

2.4 Example

Hereafter, we specify various properties using the

logic L

• (−send)

: this formula is satisﬁed by inﬁnite

traces that do not contain the action send.

• (−read)

∗

(read.(−send)

) : this formula repre-

sents a security property which prohibits a send

operation after a read has been executed.

2.5 Derivative

In this subsection, we adapt the notion of Brzozowski

derivatives or "residuals" (see (Brzozowski, 1964;

Owens et al., 2009; Sen and Rosu, 2003) for more de-

tail) to our logic. The notion of derivatives expresses

the idea of "program evolution", in the sense that it

gives the remaining part of a program after the exe-

cution of a given action. Similarly, the derivative of

a formulae ϕ with respect to an atomic action a, de-

noted by [ϕ]

, is the remaining part of ϕ that needs to

be respected by an arbitrary trace t so that a.t respects

ϕ. More formally, the deﬁnition of the derivative is as

shown in Table 3.

Hereafter, we extend the deﬁnition of derivative to

an arbitrary trace as follows:

Deﬁnition 1. Let ϕ be a formula in L

, ξ a trace in T ,

and a an action in A . The derivative of ϕ with respect

to ξ denoted by [ϕ]

is deﬁned as follows:

• [ϕ]

= ϕ

• [ϕ]

a.ξ

= [[ϕ]

]

Deﬁnition 2. Let ϕ be a formula in L

, ξ a trace in

T , and a an action in A .

• We say that a trace ξ satisﬁes the formula ϕ, de-

noted by ξ  ϕ, if ξ ∈ JϕK.

• We say that a trace ξ preﬁx-satisﬁes a formulae ϕ,

denoted by ξ|∼ ϕ, if there exists a trace ξ

′

such

that ξ.ξ

′

 ϕ.

Proposition 2.1. Let ϕ be a formula in L

and ξ a

trace in T . The following notations are equivalent:

• ξ|∼ ϕ

• [ϕ]

6= f f

• ∃x | ξ.x  ϕ

Proof. The proof follows directly from the deﬁnition

of |∼ and . 2

SECRYPT 2010 - International Conference on Security and Cryptography

Table 2: Semantics of L

formulae.

JttK = T

J f fK =

J1K = {ε}

JaK = {a}

Jϕ

.ϕ

K = {ξ

.ξ

|ξ

∈ Jϕ

K and ξ

∈ Jϕ

Jϕ

∨ ϕ

K = Jϕ

K ∪ Jϕ

Jϕ

∧ ϕ

K = Jϕ

K ∩ Jϕ

Jϕ

∗

K =



Jϕ

∗

∪ {ξ

.ξ

|ξ

∈ Jϕ

∗

and ξ

∈ Jϕ

K} If Jϕ

K 6=

Jϕ

elsewhere

J¬ϕK = T \ JϕK

Table 3: Derivative of a formula.

[−]

−

: L

× A → L

[tt]

= tt

[ f f]

= f f

[1]

= f f

[a]

= 1

[b]

= f f Where a 6= b

[ϕ

.ϕ

]



[ϕ

]

.ϕ

∨ [ϕ

]

if o(ϕ

) = 1

[ϕ

]

.ϕ

if o(ϕ

) = 0

[ϕ

∨ ϕ

]

= [ϕ

]

∨ [ϕ

]

[ϕ

∗

]

= [ϕ

]

.ϕ

∗

∨ [ϕ

]

[¬ϕ]

= ¬[ϕ]

3 PROGRAM SPECIFICATION

In this section, we present the formal language that

we use to specify concurrent programs. It is a modi-

ﬁed version of ACP (Algebra of Communicating Pro-

cesses) which is developed by Jan Bergstra and Jan

Willem Klop in 1982 (Baeten, 2005). This new alge-

bra, denoted ACP

, has the particularity of explicitly

handling the monitoring concept through its operator

"∂

". For instance, the process ∂

(P) can execute only

actions that preﬁx-satisﬁes the security policy φ. This

process algebra is a powerful language for specifying

and studying concurrent systems. It provides a mod-

ular tool for the high-level description of interactions,

communications and synchronizations between a col-

lection of processes.

3.1 Syntax

The syntax of ACP

is presented by the BNF grammar

in Table 4. Note that the merge operator ||

and the

communication operator |

are parameterized by the

communication function γ as deﬁned hereafter:

Deﬁnition 3 (Communication Function). A com-

munication function is any commutative and associa-

tive function form A × A to A , i.e.: γ : A × A → A is

a communication function if:

1. ∀a, b ∈ A , : γ(a, b) = γ(b, a), and

2. ∀a, b, c ∈ A : γ(γ(a, b), c) = γ(a, γ(b, c)).

Table 4: Syntax of ACP

P ::= 1 | δ | a | P

| P

+ P

| P

∗

| ∂

(P) | τ

(P) | ∂

(P)

Essentially, a process is either an atomic action or

a combination of others processes according to some

well deﬁned operators. Constants 1 and δ represent

the successful termination and the deadlock respec-

tively. Constants a, b, c, . . . are called atomic actions.

The operator "." represents the sequential composi-

tion: P

is the process that ﬁrst executes P

until it

terminates, and then P

starts. The operator "+" repre-

sents the alternative composition: P

+ P

represents

the process that either executes P

or P

but not both

of them. The merge operator "||

" represents the par-

allel composition: P

is the process that executes

and P

in parallel with the possibility of synchro-

nization according to the function γ. Notice that the

function γ can change from one composition to an-

other. For instance, (P

is a valid process,

where γ

6= γ

. The left merge operator "T

" has the

same meaning as the merge operator, but with the re-

striction that the ﬁrst step must come from the left

process: P

is the process that ﬁrst executes an

action in P

and then run the remaining part of P

in parallel with P

. The communication operator "|

represents a synchronized composition (communica-

tion between processes). Thus, P

represents the

merge of two processes P

and P

with the restriction

that the ﬁrst step is a communication between P

and

. The operator "∗" represents the iteration. It is a bi-

nary version of the Kleene star operator (Bergstra and

Ponse, 2001): P

∗

is the process that behaves like

.(P

∗

) + P

. The unary operator "∂

" represents a

restriction operator, where H ⊆ A : the process ∂

(P)

can evolve only by executing actions that are not in

REWRITING-BASED SECURITY ENFORCEMENT OF CONCURRENT SYSTEMS - A Formal Approach

H. The unary operator "τ

" represents the abstraction

operator, where I is any set of atomic actions called

internal actions: it abstracts all output action in I by

the silent action τ. Finally, the operator "∂

", where

φ is a L

formula and ξ is a trace from T , represents

our enforcement operator: ∂

(P) is the processes that

can evolve only if P can evolve by actions that do not

lead to the violation of the security policy φ. In the

sequel, we denote by P the set of processes generated

by ACP

3.2 Semantics

The operational semantics of ACP

is deﬁned by the

transition relation −→∈ P × A × P shown in table 6,

where the relation "≡" is deﬁned in Table 5.

Table 5: Axiom of ACP

P+ Q ≡ Q+ P P||

Q ≡ Q||

Q ≡ Q|

P P+ δ ≡ P

δ.P ≡ δ 1.P ≡ P

In the following we deﬁne an ordering relation, noted

⊑, on processes.

Deﬁnition 4 (Order Relation). Let P and Q be

two processes in P . We say that P is smaller tan

Q, denoted by P ⊑ Q, if the following condition is

satisﬁed:

−→ P

′

then Q

−→ Q

′

and P

′

⊑ Q

′

4 FORMAL ENFORCEMENT OF

SECURITY POLICIES

The principal goal of this research is to deﬁne a for-

mal framework allowing to enforce security policies

on concurrent programs. To achieve this goal, we de-

ﬁned a logic which is suitable for to the speciﬁcation

of our targeted class of security policies and we used

a version of ACP calculus enhanced with an enforce-

ment operator ∂

for the speciﬁcation of concurrent

programs. The following theorem states that the de-

sired enforcement can be achieved by the operator ∂

−

Theorem 4.1. Let P be a process in ACP

and φ a

formula in L

. Let ⊗ : ACP

× L

→ ACP

be de-

ﬁned by P⊗φ = ∂

(P). The following three properties

hold:

(i) P⊗ φ|∼ φ,

(ii) P⊗ φ ⊑ P and

(iii) ∀ P

′

: ((P

′

|∼ φ) ∧ (P

′

⊑ P)) ⇒ P

′

⊑ P⊗ φ.

Proof.

(i) ∂

(P)|∼ φ: This follows directly from the se-

mantics of ACP

which was deﬁned in such a way

that ∂

(P) can evolve only when the security policy is

respected rule (R

∂

) of table 6.

(ii) ∂

(P) ⊑ P: This also followsdirectly from the rule

∂

) of table 6.

(iii) Let P

′

be a process such that : P

′

|∼ φ∧ P

′

⊑ P

and suppose that P

′

−→ P

′

. Since P

′

⊑ P, it follows

from the deﬁnition of ⊑ that P

−→ P

. Since P

′

|∼ φ it

follows, from the deﬁnition of |∼, that a|∼ φ. Finally,

since implies that P

−→ P

and a|∼ φ it follows from

the the rule (R

∂

) in table 6 that ∂

(P)

−→ ∂

) and

we conclude that P

′

⊑ ∂

(P) = P⊗ φ. 2

Some of the important features of the enforcement

operator is that it allows us to enforce locally a given

security policy e.g.: P.∂

(Q), P | ∂

(Q), etc. This al-

lows to reduce the overhead induced by the monitor-

ing when the untrusted part of the system are known.

Besides, the enforcement operator allows us to en-

force different policies in different parts of the sys-

tem, e.g. ∂

′

(P).∂

(Q), ∂

′

(P) | ∂

(Q), etc. However,

the inconvenience of this operator is that its imple-

mentation could be heavy and the result could be not

efﬁcient. In fact, as shown by the rule (R

∂

) of Table

6, we need to save the history of the execution of a

process and we need to check that any new requested

action cannot violate the security policy when added

to the history. Another future interesting point is to

compare the expressiveness of the ACP

with ACP.

In the rest of this paper we prove that the enforce-

ment operator ∂

(P) does not bring any additional ex-

pressivity to the language since it can be expressed as

a combination of the rest of the operators in ACP

In addition to the importance of this result from the

theoretical point of view, it gives us an efﬁcient and

elegant way to implement our enforcement operator.

Basically, the idea consists in transforming the secu-

rity policy as a process that runs in parallel with the

system. The controlled system will be modiﬁed by

adding some synchronization actions so that it can

evolve only when the requested action is allowed by

the security policy.

Normal Form of L

Formulas. In the sequel, we

show how to transform a formula in L

, specifying a

given security policy, as a process in ACP

so that it

could follow the analyzed system step by step and for-

bid it whenever it tries to violate the security policy.

SECRYPT 2010 - International Conference on Security and Cryptography

Table 6: Operational semantics of ACP

≡

)

P ≡ P

−→ P

≡ Q

−→ Q

)

−→ 1

)

−→ P

′

P.Q

−→ P

′

)

−→ P

′

P+ Q

−→ P

′

∗

)

−→ P

′

∗

−→ P

′

.(P

∗

)

−→ Q

′

∗

−→ Q

′

)

−→ P

′

−→ P

′

)

−→ P

′

P||

−→ P

′

)

−→ P

′

−→ Q

′

P||

γ(a,b)

−→ P

′

γ(a, b) 6= δ (R

)

−→ P

′

−→ Q

′

γ(a,b)

−→ P

′

γ(a, b) 6= δ

)

−→ P

′

(P)

−→ τ

′

)

a ∈ I (R

)

−→ P

′

(P)

−→ τ

(P)

a 6∈ I

∂

)

−→ P

′

∂

(P)

−→ ∂

′

)

a 6∈ H (R

∂

)

−→ P

′

∂

(P)

−→ ∂

ξ.a

′

)

ξ.a|∼ φ

Of course, the process reﬂecting the formula, must,

amongst others, produce the same traces given by the

semantic of the formula. Also, we should be able to

ﬁnd an equivalence representation of any operator of

the logic in ACP

. Operators like "." and "∗" of the

logic will be easily transformed into the same oper-

ators in ACP

. However, the situation is different

when we want to translate operators that are in L

and not in ACP

such as the conjunction or the nega-

tion. Some operators have their corresponding one in

ACP

, like the disjunction that can be translated to a

choice, but they have different algebraic properties. In

fact, as processes, a.(b+ c) and a.b + a.c do not have

the same behaviours but as a formulae, a.(b∨ c) and

a.b∨ a.c has the same semantics. Therefore, one can

ask the question what is the appropriate translation of

the formula a.b ∨ a.c? Is it a.(b + c) or a.b + a.c?

In fact, the ﬁrst choice is more appropriate since it al-

lows monitoring the analyzed system according to the

following idea: the system cannot evolve only if the

process capturing the formula can evolve. So if our

system is a.(b + c) and our formula is a.b∨ a.c and

we capture the formula by the process a.b+ a.c, there

is a risk that the system will be blocked even if it is

trivial that all its traces respect the formula.

We deﬁne a transformation function that rewrites

a logical formula to an equivalent one, called normal

form formula, so that the translation from the formula

to the process could be easily achieved. This normal-

ization involves the following three kind of transfor-

mation:

Conjunctive Normal Form. A formula is in CNF

(Conjunctive Normal Form) if it is a conjunction of

terms, where a term is a disjunction of literals. More

formally, it is formulae of the form

i∈1..n

where each

does not contain the conjunction operation. We

will show later how we can enforce a formula in CNF.

Elimination of the Form ¬ϕ. Since the negation

operator in L

has not any "equivalent" one in ACP

then we need to removeit as following: ﬁrst, we trans-

form a formula of the form ¬ϕ in such a way that

the scope of the negation operator will be limited to

atomic actions. For instance, the formula ¬(ab) will

be transformed to ¬a∨ a.¬b . After that the negation

of an atomic action will be eliminated using its com-

plimentary part as it will be shown later.

Deterministic Formula. To resolve the problem of

the disjunction operator, we need to ﬁnd its equiva-

lent deterministic form which always exists since we

restricted our logic L

so that the star operator is al-

ways deterministic. We can prove that this determin-

istic form is the normal form of the rewriting system

composed by the rule: a.ϕ

∨ a.ϕ

→ a.(ϕ

∨ ϕ

In the rest of the document, we will consider only

formula in L

that are in their normal form "

i∈1..n

This set is denoted by L

N(ϕ)

. Moreover, the set of

terms (ϕ

) that does not contain the conjunction oper-

ator will be denoted by L

N(ϕ)

REWRITING-BASED SECURITY ENFORCEMENT OF CONCURRENT SYSTEMS - A Formal Approach

Synchronization Actions. The idea of transform-

ing a formula to a process that monitors the system

is achieved via the introduction of what we call syn-

chronization actions (commonly used in synchroniza-

tion logic). Let us clarify the idea by a simple ex-

ample. Suppose that the process is a+ b and the se-

curity policy is φ = a which means that only the ac-

tion a is allowed. To monitor the process, the secu-

rity policy will be transformed as a process contain-

ing only synchronization actions where each action a

is replaced by a sequence of two actions a

used

to capture the start and the end of the action a. There-

fore, the formula a will be captured by the monitor

= a

. The process, on the other hand, will be

modiﬁed to include the complimentary part of these

synchronizations actions in such a way that each ac-

tion a will be replaced by a

.a.a

. For example, the

process a+b will be transformed to a

.a.a

.b.b

Now, when the two processes are executed in paral-

lel (a

.a.a

+ b

.b.b

) |

they can communi-

cate (synchronize) on their synchronization actions if

γ allows it. Now, to really enforce, the security pol-

icy we need to force the synchronization using the

∂

. i.e.: ∂

((a

.a.a

+ b

.b.b

) |

), where

H = {a

, a

, b

, a

}. Finally, we clean the out-

put stream of the process by abstracting the communi-

cation on synchronization actions by the silent action

τ as follows: τ

(∂

((a

.a.a

+ b

.b.b

) |

)),

where I = {γ(a

, a

)}. The ﬁnal version is the en-

forced version of the system with the security policy

φ that behaves as expected.

To formalize, this idea, we need to introduce the

following ingredients:

• Given a set of actions A, the corresponding syn-

chronization set, denoted by A

is:

[

a∈A

, a

}

So A

will denote the set of synchronization ac-

tion associated with A . Moreover, for any process

P, A

(P) returns the set of synchronization ac-

tions in P.

• The process a

where a is in A

is:

∑

α∈A

\{a}

• For any integer i, the set A

is the version of A

indexed by an integer i :

[

a∈A

}

• The set H

will be used to denote the set A

• The set I

will be used to denote the set

[

α∈A

{α|

α}.

• The function γ

will be used to denote the com-

munication function deﬁned as follows:

(a, ¯a) =



a| ¯a if a ∈ A ∪ A

δ else

From Formula to Process: Translation Function.

The translation function is deﬁned as shown in Table

Table 7: L

formulae translation function.

⌈|−|⌉ : L

N(ϕ)

× N → ACP

⌈|tt|⌉

= (

∑

α∈A

.α

)

∗

∑

α∈A

.α

+ 1

⌈| f f|⌉

= δ

⌈|1|⌉

= 1

⌈|δ|⌉

= δ

⌈|a|⌉

= a

⌈|φ

.φ

|⌉

= ⌈|φ

|⌉

.⌈|φ

|⌉

⌈|φ

∨ φ

|⌉

= ⌈|φ

|⌉

+ ⌈|φ

|⌉

⌈|φ

∗

|⌉

= ⌈|φ

|⌉

∗

⌈|φ

|⌉

⌈|¬a|⌉

= a

.((

∑

α∈A

.α

)

∗

∑

α∈A

.α

+ 1)

Adding Synchronization Actions to Process. Syn-

chronization actions are added in a process by the

function ⌈−⌉ deﬁned in Table 8 where the function

(P) returns the set of synchronization actions in P.

Table 8: ACP

Processes translation function.

⌈−⌉ : ACP

× N × 2

→ ACP

⌈1⌉

= 1

⌈δ⌉

= δ

⌈a⌉



a If a ∈ H ∪ {τ}

.a.a

Else

⌈P

⌉

= ⌈P

⌉

.⌈P

⌉

⌈P

+ P

⌉

= ⌈P

⌉

+ ⌈P

⌉

⌈P

∗

⌉

= ⌈P

⌉

∗

⌈P

⌉

⌈P

⌉

= ⌈P

⌉

⌈P

⌉

⌈P

⌉

= ⌈P

⌉

T⌈P

⌉

⌈P

⌉

= ⌈P

⌉

|⌈P

⌉

⌈∂

′

(P)⌉

= ∂

′

(⌈P⌉

H∪H

′

)

⌈τ

(P)⌉

= τ

(⌈P⌉

H∪I

)

⌈∂

j∈1..n

(P)⌉

= ⌈∂

j∈2..n

⌈∂

(P)⌉

⌉

H∪H

i+1

⌈∂

(P)⌉

= ∂

(τ

(⌈P⌉

⌈|[ϕ]

|⌉

))

where H

= A

(⌈∂

(P)⌉

)

SECRYPT 2010 - International Conference on Security and Cryptography

Enforced Version ∂

(P). Now, we are ready to ex-

press the enforcement operator using the standard

ACP operators. Indeed, we’ll prove in the next sec-

tion that the process ∂

(P) is "equivalent" to the pro-

cess ∂

(τ

(⌈P⌉

⌈|[ϕ]

|⌉

)) for any integer i.

5 MAIN RESULT

The purpose of this section is to prove that enforce-

ment process can be speciﬁed in ACP. The initial

version of the process in ACP

and its correspond-

ing version in ACP are equivalent with respect to the

τ-bissimulation deﬁned hereafter:

Deﬁnition 5 (τ-bissimulation). A binary relation

S ⊆ P × P over processes is a τ-bissimulation, if

(P, Q) ∈ S implies:

(i) If P

։ P

′

then Q

։ Q

′

and (P

′

, Q

′

) ∈ S, and

(ii) If Q

։ Q

′

then P

։ P

′

and (Q

′

, P

′

) ∈ S

where

։= (

→)

∗

→ (

→)

∗

Deﬁnition 6 (↔

). We deﬁne ↔

as the biggest

τ-bissimulation:

↔

{S : S is a τ-bissimulation }

Finally, The following theorem states the equiva-

lence between the enforcement operator and its trans-

formation.

Theorem 5.1 (Main Theorem). ∀P ∈ ACP

∀ϕ ∈ L

N(ϕ)

, and ∀ξ ∈ T , we have :

∂

(P)↔

∂

(τ

(⌈P⌉

⌈|[ϕ]

|⌉

))

for any i ∈ N.

6 EXAMPLE

Hereafter we show how our techniques works on

a simple example. We consider the program P =

read.copy||

write.send, which is composed of two

concurrent processes, and the property given by the

following formulae ϕ : (−read)

∗

(read.(−send)

In order to enforce ϕ on the program P, we execute

the process : ∂

(read.copy||

write.send). Which is

equivalent to execute the process :

∂

(τ

(⌈read.copy||

write.send⌉

⌈|[(−read)

∗

(read.(−send)

)]

|⌉

)).

In order to simplify the presentation, the letter c

denotes copy, the letter r denotes read, the letter w

denotes write and the letter s denotes send.

Firstly, we should calculate ⌈r.c||

w.s⌉

and

⌈|[(−r)

∗

(r.(−s)

)]

|⌉

⌈r.c||

w.s⌉

= r

.r.r

.c.c

.w.w

.s.s

⌈|[(−r)

∗

(r.(−s)

)]

|⌉

= (r

)

∗

.(s

)

We obtain the following process :

∂

(τ

((r

.r.r

.c.c

.w.w

.s.s

)||

)

∗

.(s

)

| {z }

)), where

= A

and I

[

α∈A

{α|

α}

For example developing the followingsequence of

actions : read.write.send. Note that this sequence

violates the property φ, and the program should be

blocked before executing the action send.

∂

(τ

((r

.r.r

.c.c

.w.w

.s.s

)||

)

∗

.(s

)

)))

−→ {| Rules R

, R

and R

∂

where

, r

) = r

∈ I

∂

(τ

((r.r

.c.c

.w.w

.s.s

)||

.(s

)

))

−→ {| Rules R

, R

and R

∂

where r 6∈ I

∂

(τ

((r

.c.c

.w.w

.s.s

)||

.(s

)

))

−→ {| Rules R

, R

and R

∂

where

, r

) = r

∈ I

∂

(τ

((c

.c.c

.w.w

.s.s

)||

.(s

)

))

−→ {| Rules R

, R

and R

∂

where

, s

) = w

∈ I

∂

(τ

((c

.c.c

w.w

.s.s

)

.(s

)

))

−→ {| Rules R

, R

and R

∂

where r 6∈ I

∂

(τ

((c

.c.c

.s.s

)||

.(s

)

))

−→ {| Rules R

, R

and R

∂

where

, s

) = w

∈ I

REWRITING-BASED SECURITY ENFORCEMENT OF CONCURRENT SYSTEMS - A Formal Approach

∂

(τ

((c

.c.c

.s.s

)||

)

))

As we can see the subprocess (c

.c.c

.s.s

)

cannot execute the action send, because it should

ﬁrstly synchronize with another process to execute the

action s

, which is impossible.

7 CONCLUSIONS

This paper presents an original and innovative con-

tribution for the enforcement of security policies on

parallel programs. We ﬁrst deﬁned a dedicated al-

gebraic calculus for the speciﬁcation of parallel pro-

grams and a dedicated logic for the speciﬁcation of

security policies. The originality of the presented cal-

culus is that it implements a special enforcement op-

erator ∂

. Thus, this research project has formally de-

ﬁned the syntax and the semantics of the speciﬁca-

tion languages and showed how these could be used

to provide mechanisms for automatic enforcement of

security requirements on parallel programs. Subse-

quently, this paper demonstrated important results of

soundness and completeness of the suggested tech-

nique. In a second step, this project was interested

in the practical aspects of the presented method and

showed how the enforcement operator could, in fact,

be deﬁned by standard ACP operators. These results

are, in fact, very important both from a theoretical and

practical perspectives and allow us to consider the ap-

plication of our method on real languages like C or

Java. Consequently, we are currently implementing

a software prototype of our method that operates on

the Java language. As a future work, we plan to ex-

tend the logic L

to give the end user the possibility to

specify the actions to be executed when the security

policy is about to be violated instead of simply halting

the execution of the program.

REFERENCES

Baeten, J. C. M. (2005). A brief history of process algebra.

Theor. Comput. Sci., 335(2-3):131–146.

Bauer, L., Ligatti, J., and Walker, D. (2002). More enforce-

able security policies. In In Foundations of Computer

Security.

Bergstra, W. F. J. A. and Ponse, A. (2001). Handbook Of

Process Algebra, chapter chapter 5 : Process Algebra

with Recursive Operations, pages 333–389. Elsevier.

Brzozowski, J. A. (1964). Derivatives of regular expres-

sions. J. ACM, 11(4):481–494.

Erlingsson, U. and Schneider, F. B. (2000). Irm enforce-

ment of java stack inspection. In SP ’00: Proceedings

of the 2000 IEEE Symposium on Security and Privacy,

page 246, Washington, DC,USA. IEEE Computer So-

ciety.

Fokkink, W. (2000). Introduction to Process Algebra.

Springer-Verlag, Berlin.

K. Hamlen, G. M. and Schneider, F. (2003). Computability

classes for enforcement mechanisms. Technical Re-

port TR2003-1908, Cornell University.

Langar, M. and Mejri, M. (2005). Formal and efﬁcient en-

forcement of security policies. In FCS, pages 143–

149.

Langar, M., Mejri, M., and Adi, K. (2007). A formal ap-

proach for security policy enforcement in concurrent

programs. In Security and Management, pages 165–

171.

Ligatti, J., Bauer, L., and Walker, D. (2005). Edit automata:

Enforcement mechanisms for run-time security poli-

cies. International Journal of Information Security,

4(1–2):2–16.

Martinell, F. and Matteucci, I. (2007). Through modeling to

synthesis of security automata. Electron. Notes Theor.

Comput. Sci., 179:31–46.

Mejri, M. and Fujita, H. (2008). Enforcing security policies

using algebraic approach. In SoMeT, pages 84–98.

Morrisett, G., Walker, D., Crary, K., and Glew, N. (1999).

From system f to typed assembly language. ACM

Trans. Program. Lang. Syst., 21(3):527–568.

Necula, G. C. (1997). Proof-carrying code. In POPL

’97: Proceedings of the 24th ACM SIGPLAN-SIGACT

symposium on Principles of programming languages,

pages 106–119, New York, NY, USA. ACM.

Ould-Slimane, H., Mejri, M., and Adi, K. (2009). Using

edit automata for rewriting-based security enforce-

ment. In DBSec, pages 175–190.

Owens, S., Reppy, J., and Turon, A. (2009). Regular-

expression derivatives re-examined. J. Funct. Pro-

gram., 19(2):173–190.

Schneider, F. B. (2000). Enforceable security policies. ACM

Trans. Inf. Syst. Secur., 3(1):30–50.

Sen, K. and Rosu, G. (2003). Generating optimal monitors

for extended regular expressions. In In Proceedings

of the 3rd Workshop on Runtime Veriﬁcation (RV

03).

Elsevier Science.

SECRYPT 2010 - International Conference on Security and Cryptography