<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Information Flow and Concurrent Imperative Languages ?</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Damas P. GRUSKA</string-name>
          <email>gruska@fmph.uniba.sk</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Institute of Informatics, Comenius University</institution>
          ,
          <addr-line>Mlynska dolina, 842 48 Bratislava</addr-line>
          ,
          <country country="SK">Slovakia</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>Information flow for concurrent imperative languages is defined and studied. As a working formalism we use UNITY, where programs consist of sets of assignments executed randomly, i.e. without control flow. We study noninterference for programs which reach and do not reach fixed point - a state which is not changed by a subsequent execution. We present logic formulation of noninterference as well as type system for it.</p>
      </abstract>
      <kwd-group>
        <kwd>information flow</kwd>
        <kwd>noninterference</kwd>
        <kwd>concurrent imperative language</kwd>
        <kwd>fixed point</kwd>
        <kwd>safety and progress properties</kwd>
        <kwd>type system</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>Several formulations of a notion of a system security can be found in the
literature. Many of them are based on a concept of noninterference (see [GM82]) which
assumes an absence of any information oflw between private and public systems
activities. More precisely, systems are considered to be secure if from observations
of their public activities no information about private activities can be deduced.
This approach has found many reformulations for different formalisms (Process
algebras, Petri nets, simple imperative programming languages, see [SM03] for
an overview, multi-threaded programs, see, for example, [SS00,VS98], and so
on), for different computational models (labeled transition systems,
deterministic models and so on) and for the nature or “quality” of observations (see, for
example, [BKMR06,Gru07]).</p>
      <p>Presence of information flow can be checked statically, i.e. on the program’s
code or system’s description, or dynamically, i.e. at runtime. In the rfist case
there are several methods, which include typing (see, for example [VSI96]), model
checking (see, for example, [HN,HB11]).</p>
      <p>The aim of the paper is to define and to study information flow in the case
of concurrent imperative languages. Concurrency brings several new challenges
with respect to sequential or parallel computations. There is no given control
flow, there is no scheduler and program may not terminate. This brings new
specific problems how to handle information flow. As a working formalism we take
? Work supported by the grant VEGA 1/1333/12.</p>
      <p>UNITY programs with corresponding specicfiation logic (see [CM88]). These
programs consist of sets of assignments which are randomly chosen at runtime.
Every run of UNITY program is infinite but it can happen that during the run
a xfied point is reached, i.e. point when a subsequent computation does not
change values of program variables, which somehow corresponds to termination.
Moreover, another source of nondeterminism comes from randomly chosen
values of variables if they are not specified at the beginning. On the other side, it
makes no sense to study covert channels caused by specicfi scheduler policy since
statements to be executed are chosen randomly (see [SS00,VS98]) and there is a
natural way how to compose programs and how to study their composition
properties. We will study noninterference for two groups of programs - those which
always reach xfied point(s) (there might by more then one) and those which
do not. We exploit techniques developed for imperative languages as well as for
process algebras. Then we characterize some of these noninterference properties
by UNITY logic and by type system.</p>
      <p>Organization of the paper. In Section 2 we present UNITY semantics, syntax
and logic. In Section 3 we present and investigate absence of information flow for
programs which reach xfied points (what somehow correspond to termination)
and in the next section we concentrate on non-terminating programs. Section 4
is devoted to logical characterizations of noninterference properties and Section
5 to the type system.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Unity</title>
      <p>In this section we briefly recall a slightly simplified version of UNITY programs
and the underlying logic for describing program properties. For more details see
[CM88].
2.1</p>
      <sec id="sec-2-1">
        <title>Syntax</title>
        <p>UNITY programs consist of three parts: declare, initially and assign sections,
while the second one is optional. Note that originally UNITY programs could
contain also section always but this is optional and does not bring anything new
for our purposes. Hence formally:</p>
        <p>Program program-name
declare declare-section
initially initially-section
assign assign-section
end</p>
        <p>The assign section, which consists of set of statements - assignments, is the
crucial part of a program. The statements are separated by 2. Each statement
consists of list of variables on the left hand side and list of expressions (of the
same length) on the right hand side.</p>
        <p>Expressions might by simple (examples: in x, y := 3, z + 2 on the right hand
side there are the simple expressions) or conditional (in x, y := 3 if y &gt; 0 ∼
2 if y &lt; 0, 4 on the right hand side there is a conditional expression, the
assignment assigns value 3 to x if y &gt; 0, value 2 if y &lt; 0 and leaves it unchanged if
y = 0 and assigns value 4 to y). Formally:
assign-section ::= s{2 s}∗
s ::= variable-list := expression-list
variable-list ::= variable{, variable}∗
expression-list ::= expression{, expression}∗
expression ::= simple-expression |conditional-expression
conditional-expression ::= simple-expression</p>
        <p>if boolean-expression
∼ simple-expression</p>
        <p>if boolean-expression</p>
        <p>We assume that if more boolean expressions within one conditional expression
are valuated as true then corresponding simple expressions have to be equal, i.e.
every execution of every statement is deterministic.</p>
        <p>Initially section assigns initial values to (some) variables. It is similar to
assign section (we use here = instead of :=) and we require that if a value of a
variable is initialized then it is done uniquely. Declare section declares types of
variables.</p>
        <p>By P 2P 0 we denote composition of programs P and P 0, respectively. The
sections of the resulting program are given by unions of corresponding sections
of P and P 0. It is assumed that there are no coniflcts between their declare and
initially sections, i.e. if a variable is declared in both programs, then it has to
have the same type and if a variable is initialized in both programs, then it has
to by initialized equally.
2.2</p>
      </sec>
      <sec id="sec-2-2">
        <title>Operational semantics</title>
        <p>The UNITY programs are executed in the following way: initial values of
variables are given in initial section or they are randomly chosen within appropriate
type if they are not initialized. By Initially(V ar) we denote set of variables
which have initialized values by initially section. In general, ∅ ⊆ Initially(V ar) ⊆
V ar, where V ar is the set of all program variables. Then execution proceeds with
randomly chosen statement, its execution and again new statement is randomly
chosen and executed. This is repeated infinitely many times in such a way that
every statement is executed innfiitely many times. Hence an underlying
semantics is given by the set of innfiite sequences (runs) R, R = R0, R1, . . . where
Ri = (Ri.state, Ri.statement) i.e. each element of the run contains state - i.e.
values of all variables (denfied by mapping υ : V ar → υ (dom)) and the
statement which is to be executed as the next. By R.state we will denote the sequence
of states of run R, i.e. R.state = R0.state, R1.state, . . .. We assume that every
statement of the program appears infinitely many times in every run. Note that
Ri+1.state is uniquely determined by Ri = (Ri.state, Ri.statement) since
execution of any statement is deterministic. R0.state is an initial state. If initial
values of all variables are given in initial section, then every run starts with this
unique initial state. Otherwise there are many possible initial states depending
on variables which are not initialized. For example, if there is only one boolean
variable not initialized, then there are two possible initial states. By initial
condition (predicate Initially) we mean condition which is given by initial section.
Roughly speaking, it is a predicate obtained from initially section by replacing
:= by =, 2 by ∧ and conditional expression x = e1 if b1 ∼ . . . ∼ en if bn is
replaced by (b0 ⇒ (x = e0)) ∧ . . . ∧ (bn ⇒ (x = en)). For simplicity we assume that
the variables have integer values. Note that considering other types of variables
does not bring anything fundamentally new with respect to studied concepts
and properties. We use 0 for false and nonzero for true. Formally, a state (we
will alternatively use also denotation memory) is defined as mapping υ which
assigns integer value to every variable, i.e. Ri.state ≡ υ : V ar → Z. The formal
denfiition of υ is the following:</p>
        <p>x ∈ dom(υ )
υ →x−:=e υ [x := υ (e)]</p>
        <p>x ∈ dom(υ )
υ x:=e if b υ [x := υ (e)] if b
→−</p>
        <p>x ∈ dom(υ )
υ x:=e if b υ if ¬b</p>
        <p>→−
υ →−s υ 0, υ 0 →−s0 υ 00</p>
        <p>υ →−s.s0 υ 00</p>
        <sec id="sec-2-2-1">
          <title>We write υ →−</title>
          <p>that υ →−t υ 0.
2.3</p>
        </sec>
      </sec>
      <sec id="sec-2-3">
        <title>Logic</title>
        <p>υ 0 if there exists a sequence of statements t = s1. . . . sn such
Let p, q are predicates and s statement. The assertion { } { } denotes that
p s q
execution of s in any state that satisefis predicate p results in a state that
satisfies predicate q.</p>
        <p>Let us consider program P which contains at least one statement. We write
s ∈ P if assign section of P contains s. We will use standard logical
operators as ∨, ∧, ¬, ⇒, . . . and moreover, we define UNITY logic operators for safety
properties unless, stable, invariant, constant and for progress properties ensures,
leads-to. We start with basic safety property unless which is denfied as follows.</p>
        <p>p unless q ≡ ∀ s, s ∈ P :: {p ∧ ¬q}s{p ∨ q}</p>
        <p>Derived operators are defined as follows: p is stable iff p unless f alse, p is
constant iff both p and ¬p are stable. Predicate p is invariant iff it is stable and
Initially ⇒ p.</p>
        <p>Now we can define two progress properties ensures, leads-to (denoted as 7→).</p>
        <p>p ensures q ≡ ∃ s, s ∈ P :: {p ∧ ¬q}s{q} and p unless q</p>
        <p>Leads-to is defined by a finite number of application of the following inference
rules. The first inference rule says that ensures is a special case of leads to.</p>
        <sec id="sec-2-3-1">
          <title>The second inference rule denfies transitivity of 7→.</title>
          <p>The third inference rule denfies weakening ( W is a set of indexes).
p ensures q</p>
          <p>p 7→ q
p 7→ q, q 7→ r</p>
          <p>p 7→ r
∀m ∈ W :: pm 7→ q
(∃m ∈ W :: pm) 7→ q</p>
          <p>By xfied point we mean a state for which it holds that for each statement
of the program valuations of variables on the left hand side and right hand side
are equal, i.e. any subsequent execution of the program does not change state of
the program. Formally,</p>
          <p>F P ≡ ∀ s ∈ P, if s is ”X := E” then X = E
where X and E is variable and expression lists, respectively. In case of conditional
expressions, if neither of conditions is evaluated to true, then the statement does
not change the value of variable on the left hand side and we consider this as
that the both sides are equal. By true 7→ F P we will denote that fixed point
will be reached.</p>
          <p>By υ p we denote that predicate p holds for valuation υ . In special case
valuation υ initially has to satisfy initial condition, i.e. if variable x initializes its value
to m than υ Initially(x) = m.
3</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Non-interference for programs with fixed points</title>
      <p>Suppose that the set of variables V ar is divided into two subsets, namely the
set of public (low level) variables V arL and private (high level) ones V arH . This
division does not vary at runtime. We denote low level variables as l, l0, l1, . . .,
high level ones as h, h0, h1, . . . and constants as c, c0, c1, . . ..</p>
      <p>First we denfie termination-insensitive security (see for example [VS97]) for
imperative programs based on an absence of information oflw between private a
and public variables.</p>
      <p>Definition 1. (BTNI) A deterministic program C satisfies batch-job
termination-insensitive noninterference (BTNI) if, for any memory (valuation)
υ 1 and υ 2 that agree on public (low) variables, the final memories υ 10 and υ 20
produced by running P also agree on public variables if both runs terminate
successfully.</p>
      <p>Roughly speaking, BTNI property requires that programs represent functions
for which low level outputs do not depend on high level inputs.</p>
      <p>Examples of programs which clearly violate BTNI condition are l := h (the
explicit information oflw) and l := 1 if h = 0 (the implicit information oflw).</p>
      <p>We cannot apply BTNI property for UNITY programs from the several
reasons. They are undeterministic, there might have several initial states of
computations and they do not terminate. So we have to elaborate new noninterference
denfiition for UNITY programs.</p>
      <p>First we need some preparatory work. Let υ 1 and υ 2 be valuations. We write
υ 0 =M υ 1 iff υ 0(x) =M υ 1(x) for every variable x, x ∈ M . We will write υ 0 =L υ 1
instead of υ 0 =V arL υ 1 i.e. if valuations υ 0, υ 1 agree on low level variables. From
now on we assume that high level variables are not initialized if it is not said
otherwise.</p>
      <p>Definition 2. Program P is called fixed point deterministic with respect to M ,
M ⊆ V ar (P ∈ F P D(M ), for short) iff it always reaches fixed point and
moreover this is unique for variables from M , i.e. values of variables from M are
equal at any fixed point.</p>
      <p>Example 1. Let us consider assignment l := l + 1 if l &lt; l0. For program P
consisting of (only) this assignment and if both values l, l0 are initialized then it is
F P D(L). If any of them, or both, are not initialized, then it is not F P D(L)
despite the fact that it always reaches xfied point but for different runs it can
reach different fixed points. On the other side, initialization of all variables is
not necessary condition to be fixed point deterministic even with respect to set
which does not contain non-initialized variables.</p>
      <p>Definition 3. Program P satisfies fixed point deterministic noninterference
(FPDNI, for short) iff it is FPD(L).</p>
      <p>For programs such that Initially(V ar) = L property FPDNI corresponds to
BT N I property (see Denfiition 1). If some low level variables are not initialized,
then it is stronger. Sometimes it might be too strong since it requires that
program reaches the same (from low level point of view) fixed point even for
low level variables which initial values are chosen randomly. We could weaken
FPDNI property by requiring that program is deterministic only with respect
to initialized low level variables.</p>
      <p>Definition 4. Program P satisfies weak fixed point deterministic
noninterference (WFPDNI, for short) iff it is F P D(Initially(V ar) ∩ L).</p>
      <p>Lemma 1. Let P satisfy fixed point noninterference then it satisfies also weak
fixed point noninterference
Proof. Clearly, if P satisfies xfied point noninterference then it is xfied point
deterministic for all low level variables and hence also for any subset of low level
variables. Note that an inverse of the lemma does not hold (see Example 1).</p>
      <p>Requiring deterministicity is a strong requirement for concurrent programs.
They often lead to different states (results) depending on factors which cannot
be predicted (say, random factors). To capture noninterference for such cases
requires a different approach. An intruder cannot learn nothing about initial
value of high level variable h, if for any computation starting with some value
of h there exists a computation starting with different value of h which leads to
the same fixed point as regards low level variables. This leads us to the following
denfiition.</p>
      <p>Definition 5. Program P satisfies fixed point noninterference with respect to
M, M ⊆ H(P ∈ F P N I(M ), for short) iff it always reaches fixed point and for
every valuation υ 0 for which it holds Initially ⇒ υ 0 there exists υ 00 for which it
holds Initially ⇒ υ 00 such that υ (x) 6= υ 0(x) for every x ∈ M and υ 0 → υ F P ,
υ 00 → υ F0 P and moreover υ F P =L υ F0 P .</p>
      <p>If program has F P N I(M ) then, then an intruder cannot learn (exact) value
of any of its high level variables from M . For F P N I(M ) property we have the
following lemma, which say that noninterference for a set of high level variables
can be obtained separately from its subsets.</p>
      <p>Lemma 2. F P N I(M1) ∩ F P N I(M2) = F P N I(M1 ∪ M2).</p>
      <p>Proof. By case analysis of all possible runs.</p>
      <p>Lemma 3. Let M1 ⊆</p>
      <p>M2 then F P N I(M2) ⊆ F P N I(M1).</p>
      <p>Proof. Directly from denfiition of F P N I(M ) property.</p>
      <p>We conclude this section by comparing above proposed noninterference
properties by the following proposition.</p>
      <p>Proposition 1. F P DN I ⊂</p>
      <p>W F P DN I ⊂ F P N I(M ) for every M, M ⊆
H.</p>
      <p>Proof. Main idea. One part of the proposition comes from Lemma 1. The other
part comes from the fact that we can always find different values of high level
variables (thanks to their domain and not being initialized as it is assumed at
the beginning of this section) for initial states and deterministic programs leads
to unique xfied point form low level point of view. The following example shows
that also this inclusion is proper.</p>
      <p>Example 2. Let us consider program P .</p>
      <p>Program P
initially l :=c
assign l := l + 1 if l &lt; l0 ∼ h if l ≥ l0
end
The program always reaches the fixed point. Then it holds l = h if c ≥ l0 and
l = l0 otherwise. Since we do not know an initial value of l0 we do not know
neither value of h. Hence P ∈ F P N I({h}) but P 6∈ W F P DN I since the final
value of l is not uniquely determined.</p>
    </sec>
    <sec id="sec-4">
      <title>Non-interference for programs without fixed points</title>
      <p>In this section we will deal with programs which do not reach any fixed point(s)
and to which the previous definitions of noninterference cannot be applied.
Definition 6. Let P be program and let R be a run of P such that R.state =
υ 0, υ 1, . . . . We say that P satisfies non-fixed point noninterference ( P ∈ N F P N I,
for short) if for every υ 00 such that υ 0 =L υ 00 there exists run R0 such that
R0.state = υ 00, υ 10, . . . such that υ i =L υ i0 for every i.</p>
      <p>N F P N I corresponds to an observer who can see values of public variables
at every state but cannot deduce from them values of private variables.
Proposition 2. Let P ∈ N F P N I, Initially(V ar) = L, and true 7→ F P is a
property of P . Then P ∈ F P N I(M ) for every M, M ⊆ H.</p>
      <p>Proof. Main idea. Let P ∈ N F P N I and true 7→ F P is a property of P . Since
all low level variables are initialized and we can emulate on low level every two
runs then we get that P ∈ F P N I(M ) for every M, M ⊆ H.</p>
      <p>Now we can formulate a compositional property for two UNITY programs
which are N F P N I.</p>
      <p>Proposition 3. Let P, P 0 ∈ N F P N I. Then it holds that P 2P 0 ∈ N F P N I
Proof. Sketch. Program P 2P 0 is obtained by set unions (with same preliminary
requirements on conflicts - see Section 1 and under our assumption that
variables from V arH are not initialized). Hence if we have a run of P 2P 0 then it
corresponds to interleaving of executions of assignments of P and P 0.</p>
      <p>Special case of unity programs are those which are low level deterministic,
i.e. there is no choice between statements which change low level variables. For
such programs it is meaningful to denfie stronger variant of NFPNI property
which requires that all runs agree on low level variables. Formally:
Definition 7. Let P be program and let R be a run of P such that R.state =
υ 0, υ 1, . . . . We say that P satisfies strong non-fixed point noninterference ( P ∈
SN F P N I, for short) if for every υ 00 such that υ 0 =L υ 00 then for every run R0
such that R0.state = υ 00, υ 10, . . . it holds υ i =L υ i0 for every i.</p>
      <p>Lemma 4. SN F P N I ⊆ N F P N I. Moreover, if P is low level deterministic
then P ∈ SN F P N I iff P ∈ N F P N I.</p>
      <p>Proof. Sketch. The first part of the proof is straightforward. If P is low level
deterministic, since there is no choice between runs from low level point of view
and there exists at least one which is identical (from low level of view) to given
run, we have that P ∈ SN F P N I iff P ∈ N F P N I.</p>
    </sec>
    <sec id="sec-5">
      <title>Logic characterization of noninterference</title>
      <p>In this section we will denfie characterization of some noninterference properties
by UNITY logic. Let P be a program, l1, . . . , ln are its (all) low level variables
and υ is its valuation. By υ K , where K = (k1, . . . , kn), we denote predicate
υ (K) ≡ (υ (l1) = k1) ∧ . . . ∧ (υ (ln) = kn).</p>
      <p>Proposition 4. Let P be a program and υ, υ 0 its two valuations. Then P has
FPDNI property iff (true 7→ F P ) ∧ ((υ F P ∧ υ F0 P ∧ υ (K) ∧ υ (K0)) ⇒ (K = K0)).
Proof. Sketch. Let P be a program with FPDNI property. The property requires
that it reaches fixed point ( true 7→ F P ) and that valuations on any fixed points
are equal with respect to low level variables. This property is expressed by (υ F P ∧
υ F0 P ∧ υ (K) ∧ υ (K0)) ⇒ (K = K0).</p>
      <p>Proposition 5. Let P be a program. Then P has NFPNI property iff ((υ 1 =L
υ 2) ∧ (υ 1 7→ υ 10)) ⇒ (υ 2 7→ υ 20) ∧ (υ 10 =L υ 20) for some υ 20.</p>
      <p>Proof. Main idea. N F P N I property requires that for every run and every its
state there exists a run with the same initial state (up to values of high level
variables) which reaches the same states (up to values of high level variables).
Proposition 6. Let P be low level deterministic. Then P ∈ SN F P N I iff υ =L
υ 0 is stable for every pair of valuations υ, υ 0of P .</p>
      <p>Proof. Main idea. Since P is low level deterministic every two runs are equal for
low level variables, i.e. every two valuations which once become equal for low
level variables remain so, i.e. equality is stable.
6</p>
    </sec>
    <sec id="sec-6">
      <title>Type system</title>
      <p>Before we define type system which can capture NFPNI property, we need some
preparatory work. We begin with program equivalency. Note that due to
mechanism of choosing statements for execution, we do not need to work with
bisimulation or other branching sensitive relations - at any point of any computation
every statements could be executed as the next one.</p>
      <p>Definition 8. We say that programs P and P 0 are equivalent (denoted P ' P 0),
if for every run R of P there exists a run R0 of P 0 such that Ri.state = Ri0.state
for every i and vice versa.</p>
      <p>Two equivalent programs exhibit exactly the same behaviour and are
indistinguishable from semantical point of view.</p>
      <p>The next lemma allow us to simplify program syntax while increasing number
of statements.</p>
      <p>Lemma 5. For every program P there exists equivalent program P 0 such that it
contains only one conditional expression on the right side of every assignment.
Proof. Sketch. We replace (split) every assignment with more conditional
expressions with a set of assignments with only one (of) conditional expression. It
is easy to prove that resulting program is equivalent to the original one.
Lemma 6. Let P ' P 0 and P ∈ N F P N I then also P 0 ∈ N F P N I.
Proof. Sketch. Two equivalent programs exhibit the same semantical behaviour
and hence satisfy the same semantically defined properties.</p>
      <p>Lemma 7. Let P ∈ N F P N I iff P 0 ∈ N F P N I where P 0 is obtained from P
by replacing every statement of P of the form x1, . . . , xn := e1, . . . , en by the
statement x1 := e12 . . . 2xn := en (we will call P 0 sequentialization of P ).
Proof. Sketch. The difference between P and P 0 is that the first one can do
parallel assignments while the second one cannot, but it can still emulate any
parallel assignments by a sequence of sequential ones.</p>
      <p>Let us consider the following type system for UNITY programs. Here c stands
for a constant (it is a special case of expression e), op for an operational symbol
which is allowed in expressions. We use two types High and Low.
` h : High
` c : Low
` e : Low
` e : High
` e : Low
[Low] ` l := e
` e : T, ` b : T
[High] ` h := e if b
[Low] ` s for every s ∈ P
[Low] ` P</p>
      <p>` l : Low
` e1 : T, ` e1 : T
` e1 op e2 : T
[High] ` h := e
` e : Low, ` b : Low
[Low] ` l := e if b
[High] ` s
[Low] ` s</p>
      <p>Type system for UNITY programs.</p>
      <p>Proposition 7. (Soudness) Let P be a UNITY program. If typing judgment
[Low] ` P 0 can be derived where P 0 is sequentialization of P then P ∈ N F P N I.
Proof. Main idea. Thanks to Lemmas 5,6 and 7 we can assume that P does
not contain more conditional expressions on the right hand side and only one
variable on left hand side. If typing judgment [Low] ` P 0 can derived then there
are no assignments to low level variable which right hand side depend on high
level variable. Hence if we have a run υ o, υ 1, . . . then regardless on values of
high level variables there exists run υ o0, υ 10, . . . such that they agree on low level
variables.</p>
      <p>Example 3. Let us consider program P and P 0 which consists of one statement
h := 1if l = 1 and l := 1if h = 1, respectively. Then we have [Low] ` P but
[Low] ` P 0 cannot be derived.</p>
      <p>We cannot obtain complete type system since we would need to differ between
high type expressions which are constant and which really depend on high level
variables. For example, l := h − h and l := c if l = h ∼ c if l 6= h is not low level
assignments while ”semantically” it is since a value of l does not depend on a
value of h.</p>
      <p>Note that the similar type systems can be applied also for other above defined
properties as SFPNI and FPDNI. Moreover if program contains, for example,
statements of type h := c for every high level variable then initial values of those
variables cannot be deduced from any fixed point. In this way we could extend
the presented type system by introducing new type Const to cover this case.
7</p>
    </sec>
    <sec id="sec-7">
      <title>Conclusions and further work</title>
      <p>In this paper we have denfied and studied information flow for concurrent
imperative languages. We had to deal with four challenges - an absence of control
flow, possibly more initial states, an absence of a scheduler which schedules
which statement is to be executed as the next and with possibly nonterminating
behaviour. Each of thess properties causes that, in general, programs cannot be
treated as functions (they are not deterministic and do not output ”nfial
values”). Our working formalism - UNITY programs and UNITY logic are very
simple but still can capture various noninterference properties. On the other
hand we can exclude covert channels produced by specicfi scheduler policies.</p>
      <p>Concurrent imperative languages are something between simple imperative
languages and models of concurrency as labeled transition systems or process
algebras, as regards treatment of noninterference. If they are ”deterministic”
and they ”terminate” (in a sense) then they could be handled as former ones
but if they are undeterministic and/or do not terminate as later ones. Hence
we have exploited ”noninterference” techniques developed for both imperative
languages as well as for process algebras. We have also characterized some of
these noninterference properties by UNITY logic and by type system.</p>
      <p>Regarding the further work, we consider to exploit an idea studied in process
algebra setting, namely property called Non-Deducibility on Composition (NDC
for short, see in [FGM03]). Program P would have property NDC if for every
program A which changes only high level variables, i.e. υ K i stable for every K,
then P 2A ' P .</p>
      <p>In [BBM94] for nondeterministic languages authors associate with a program
variable x a set of called security variable of x, denoted x¯. It is the set of all
variables whose values can inuflence the value of x (directly or undirectly). This
approach could be used also for UNITY programs.</p>
      <p>Another possible direction of a further research might be quantification of
information obtained from low level variables. For example, program l := 1
if (h mod 2) = 1 ∼ 0 if (h mod 2) 6= 1 cannot leak exact value of h but it leaks
via l parity of h. By similar techniques as it was done in [CHM07] we could try
to quantify an amount of information on high level variables obtained from low
level ones via information theory.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <string-name>
            <surname>[BBM94] Banatre</surname>
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Bryce</surname>
          </string-name>
          and
          <string-name>
            <given-names>D.</given-names>
            <surname>Le Metayer</surname>
          </string-name>
          :
          <article-title>Compile-time Deytection of Informatioin Flow in Sequential Programs</article-title>
          .
          <source>European Symposium on Research in Computer Security, LNCS 875</source>
          , Springer, Berlin,
          <year>1994</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <surname>[BKMR06] Bryans</surname>
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Koutny</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Mazare</surname>
          </string-name>
          and
          <string-name>
            <given-names>P.</given-names>
            <surname>Ryan</surname>
          </string-name>
          <article-title>: Opacity Generalised to Transition Systems</article-title>
          .
          <source>In Proceedings of the Formal Aspects in Security and Trust, LNCS 3866</source>
          , Springer, Berlin,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [CHM07]
          <string-name>
            <surname>Clark D.</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          <string-name>
            <surname>Hunt</surname>
            and
            <given-names>P.</given-names>
          </string-name>
          <string-name>
            <surname>Malacaria</surname>
          </string-name>
          :
          <article-title>A Static Analysis for Quantifying the Information Flow in a Simple Imperative Programming Language</article-title>
          .
          <source>The Journal of Computer Security</source>
          ,
          <volume>15</volume>
          (
          <issue>3</issue>
          ).
          <year>2007</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [CM88]
          <string-name>
            <surname>Chandy</surname>
            ,
            <given-names>K. M.</given-names>
          </string-name>
          and
          <string-name>
            <surname>J.</surname>
          </string-name>
          <article-title>Misra: Parallel Program Design</article-title>
          . Addison-Wesley
          <year>1988</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [FGM03]
          <string-name>
            <surname>Focardi</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Gorrieri</surname>
          </string-name>
          , and
          <string-name>
            <given-names>F.</given-names>
            <surname>Martinelli</surname>
          </string-name>
          <article-title>: Real-Time information flow analysis</article-title>
          .
          <source>IEEE Journal on Selected Areas in Communications</source>
          <volume>21</volume>
          (
          <year>2003</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [HN]
          <string-name>
            <surname>Huisman</surname>
            <given-names>M.</given-names>
          </string-name>
          and
          <string-name>
            <surname>T.M.</surname>
          </string-name>
          <article-title>Ngo: Scheduler-specific Confidentiality for Multithreaded Programs</article-title>
          and
          <article-title>Its logic-based Verification</article-title>
          .
          <source>In proceedings of Formal Verification of Object-Oriented Systems (FoVeOos</source>
          <year>2011</year>
          ). LNCS, Springer. To appear.
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [HB11]
          <string-name>
            <surname>Huisman</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          <article-title>and</article-title>
          <string-name>
            <surname>H.-C.</surname>
          </string-name>
          <article-title>Blondeel: Model-checking Secure Information Flow for Multi-Threaded Programs</article-title>
          .
          <source>In Proceedings of Theory of Security and Applications (Tosca) LNCS</source>
          <volume>6993</volume>
          , pages
          <fpage>148</fpage>
          -
          <lpage>165</lpage>
          , Springer,
          <year>2011</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          <string-name>
            <surname>[GM82] Goguen</surname>
            <given-names>J.A.</given-names>
          </string-name>
          and
          <string-name>
            <given-names>J.</given-names>
            <surname>Meseguer</surname>
          </string-name>
          <article-title>: Security Policies and Security Models</article-title>
          .
          <source>Proc. of IEEE Symposium on Security and Privacy</source>
          ,
          <year>1982</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [Gru09]
          <string-name>
            <surname>Gruska</surname>
            <given-names>D.P.</given-names>
          </string-name>
          :
          <article-title>Quantifying Security for Timed Process Algebras, Fundamenta Informaticae</article-title>
          , vol.
          <volume>93</volume>
          ,
          <string-name>
            <surname>Numbers</surname>
          </string-name>
          1-
          <issue>3</issue>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [Gru08]
          <string-name>
            <surname>Gruska</surname>
            <given-names>D.P.</given-names>
          </string-name>
          :
          <article-title>Probabilistic Information Flow Security</article-title>
          .
          <source>Fundamenta Informaticae</source>
          , vol.
          <volume>85</volume>
          ,
          <string-name>
            <surname>Numbers</surname>
          </string-name>
          1-
          <issue>4</issue>
          ,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [Gru07]
          <string-name>
            <surname>Gruska</surname>
            <given-names>D.P.</given-names>
          </string-name>
          :
          <article-title>Observation Based System Security</article-title>
          .
          <source>Fundamenta Informaticae</source>
          , vol.
          <volume>79</volume>
          ,
          <string-name>
            <surname>Numbers</surname>
          </string-name>
          3-
          <issue>4</issue>
          ,
          <year>2007</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [SM03]
          <string-name>
            <surname>Sabelfeld</surname>
            ,
            <given-names>A</given-names>
          </string-name>
          and
          <string-name>
            <surname>A.C. Myers</surname>
          </string-name>
          :
          <string-name>
            <surname>Language-Based Information-Flow</surname>
            <given-names>Security</given-names>
          </string-name>
          ,
          <source>IEEE Journal on Selected Areas in Communications</source>
          ,
          <volume>21</volume>
          (
          <issue>1</issue>
          ):
          <fpage>5</fpage>
          -
          <lpage>19</lpage>
          ,
          <year>January 2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [SS00]
          <string-name>
            <surname>Sabelfeld</surname>
            ,
            <given-names>A</given-names>
          </string-name>
          and
          <string-name>
            <given-names>D.</given-names>
            <surname>Sands</surname>
          </string-name>
          :
          <article-title>Probabilistic Noninterference for MultiThreaded Programs</article-title>
          ,
          <source>Proceedings of the 13th IEEE workshop on Computer Security Foundations</source>
          ,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [Sch00]
          <string-name>
            <surname>Schneider</surname>
            ,
            <given-names>F. B.</given-names>
          </string-name>
          :
          <article-title>Enforceable Security Policies</article-title>
          .
          <source>ACM Transactions on Information and System Security</source>
          , Volume
          <volume>3</volume>
          Issue 1,
          <string-name>
            <surname>Feb</surname>
          </string-name>
          .
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [VS98]
          <string-name>
            <surname>Volpano D.</surname>
            and
            <given-names>G.</given-names>
          </string-name>
          <string-name>
            <surname>Smith</surname>
          </string-name>
          <article-title>: Secure Information Flow in a Multi-threaded Imperative Language</article-title>
          ,
          <source>Proc. 25th ACM Symposium on Principles of Programming Languages</source>
          , pp.
          <fpage>355</fpage>
          -
          <lpage>364</lpage>
          , San Diego, CA,
          <year>Jan 1998</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          [VS97]
          <string-name>
            <surname>Volpano D. M</surname>
            . and
            <given-names>G.</given-names>
          </string-name>
          <string-name>
            <surname>Smith</surname>
          </string-name>
          <article-title>: Eliminating Covert Flows with Minimum Typings</article-title>
          .
          <source>In Proc. CSFW</source>
          ,
          <year>1997</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          [VSI96]
          <string-name>
            <surname>Volpano D.</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          <string-name>
            <surname>Smith</surname>
            and
            <given-names>C.</given-names>
          </string-name>
          <article-title>Irvine: A Sound Type System for Secure Flow Analysis</article-title>
          ,
          <source>Journal of Computer Security</source>
          , Vol.
          <volume>4</volume>
          , No.
          <issue>3</issue>
          , pp.
          <fpage>167</fpage>
          -
          <lpage>187</lpage>
          ,
          <year>1996</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>