Static Security Certification of Programs via Dynamic Labelling
Sandip Ghosal
1
, R. K. Shyamasundar
1
and N. V. Narendra Kumar
2
1
Department of Computer Science and Engineering, Indian Institute of Technology Bombay, Mumbai, 400076, India
2
Institute for Development and Research in Banking Technology, Hyderabad, India
Keywords:
Language-based Security, Information-flow Security, Dynamic Labelling.
Abstract:
Programming languages are pivotal for building robust secure systems, and language-based security platforms
are very much in demand for building secure systems. In this paper, we explore an approach for static security
certification of a class of imperative programs using a hybrid of static and dynamic labelling via information
flow control (IFC) models. First, we illustrate an analysis of some benchmark programs using static (or
immutable) labelling approaches, and discuss possible labelling of the principals/subjects and objects using a
combination of mutable and immutable labelling, and discuss their impact on the precision of the underlying
certification. Then, we describe our approach of static certification of programs based on a combination of
mutable and immutable (i.e., hybrid) labelling; our labelling generates labels from the given set of initial labels
(some of which could be immutable) and the constraints require to be satisfied for a program to be information-
flow secure as defined by Denning et. al.(Denning and Denning, 1977). Our labelling algorithm is shown to
be sound with respect to non-interference, and we further establish the termination of the algorithm. Our
proposed labelling approach is more security precise than the other labelling approaches in the literature. It
may be pointed out that the labels are generated succinctly without unnecessarily blowing up the label space.
As the method is not tied to any particular security model, it provides a sound basis for the security certification
of programs for information-flow security. We compare the precision realizable by our approach with those
in the literature. The comparison of our approach also brings to light an intrinsic property of our labelling
algorithm that could be effectively used for non-deterministic or concurrent programs.
1 INTRODUCTION
The seminal work of Denning (Denning, 1976) on se-
curity certification of programs built on information-
flow security led to a firm foundation for language-
based security. The extension of such a theory
through the proposal of the Decentralized Label Mo-
del (DLM) (Myers and Liskov, 2000) provided a
momentum for language-based security. Since then
there has been an enormous amount of literature on
language-based security (Myers, 1999; Myers et al.,
2001; Simonet and Rocquencourt, 2003; Stefan et al.,
2012b). There have also been many assessments of
the status of language-based security (Ryan et al.,
2001; Sabelfeld and Myers, 2003; Hicks et al., 2007).
With the need for security everywhere including IoT,
language-based security is becoming prominent as it
deals with security at various levels, and also provides
various points of leaks and attacks.
Non-interference was developed after Denning’s
security certification as a more semantic characte-
rization of security (Goguen and Meseguer, 1982),
followed by many extensions. Informally the non-
interference property says the impact on the pro-
gram due to changes in high inputs should not be
observable by the low outputs. (Volpano et al.,
1996) have used a purely value-based interpretation
of non-interference as a semantic characterization of
information-flow, and derived sound typing rules to
effectively capture Denning’s certification semantics.
Volpano et. al.’s notion of non-interference, and
its extensions have become the de-facto standard for
the semantics of information-flow in the literature on
language-based security. Usually, the objective of
IFC is to enforce non-interference property to ensure
end-to-end flow security.
A broad spectrum of information-flow security
mechanisms vary from fully dynamic ones e.g., in the
form of execution-monitors (Askarov and Sabelfeld,
2009; Austin and Flanagan, 2009) to static ones e.g.,
in the form of type systems (Volpano et al., 1996).
While one would prefer static labels as that leads to
certification of programs at compile-time, it has the
problem of classifying programs that would not leak
234
Ghosal, S., Shyamasundar, R. and Kumar, N.
Static Security Certification of Programs via Dynamic Labelling.
DOI: 10.5220/0006868602340245
In Proceedings of the 15th International Joint Conference on e-Business and Telecommunications (ICETE 2018) - Volume 2: SECRYPT, pages 234-245
ISBN: 978-989-758-319-3
Copyright © 2018 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

any information under the information-flow policy at
execution time due the underlying inputs that arrive at
run-time. Real-world web applications often require
to interact with external environment that cannot be
predicted during compile-time which motivates rese-
archers to enforce security at run-time. For instance,
security settings of files and database records are up-
dated frequently, and these changes might affect the
information flow control which cannot be handled by
static mechanisms. Dynamic labels are essential to
capture the changes in security label and accordingly
labels are changed at run-time. However, unlike static
or immutable labelling implementation, dynamic me-
chanism has a cost that user has to pay in the form of
large run-time overhead, and also implicit flows intro-
duced due to uncovered flow paths not considered at
run-time. Hence, an ideal label-checking mechanism
should have a hybrid labelling that would have a nice
trade off for mutable and immutable labels to realize
acceptable precision and performance.
In this paper, we first discuss various labelling ap-
proaches that use a combination of attributes like mu-
table, immutable, static, compile-time, run-time etc.,
for the security certification along with the correspon-
ding realizable precision of security. With such a
comparison in hand, we propose a new hybrid (mu-
table and immutable) labelling approach for certi-
fying programs for information-flow security using
the standard certification of constraints as elaborated
by Denning. Our dynamic labelling algorithm is esta-
blished to be sound with respect to non-interference,
and we further prove the termination of the algorithm.
Our proposed labelling algorithm leads to certifica-
tion that is more security precise than other labelling
approaches in the literature. It may be pointed out
that the labels are generated succinctly without un-
necessarily blowing up the label space. As the met-
hod is not tied to any particular security model, it
provides a sound basis for the security certification
of programs for information-flow security. We furt-
her compare the precision realizable by our approach
with those in the literature. The comparison of our
approach also brings to light, an intrinsic property of
our labelling algorithm that could be effectively used
for non-deterministic or concurrent programs.
Structure of the Paper: Section 2 presents dif-
ferent labelling schemes, and assess the limitations
of them. Section 3 describes the proposed dyna-
mic labelling algorithm along with illustrative exam-
ples, and proofs of characteristic properties as well as
soundness with respect to non-interference. Section
4 provides a comparison with earlier approaches. Fi-
nally, Section 5 summarizes the contributions along
with the ongoing work.
2 CERTIFICATION OF
PROGRAMS
According to Denning’s Information Flow Model
(DFM) the necessary and sufficient condition for the
flow security of a program P is: if there is an informa-
tion flow from object x to object y, denoted by x → y,
the flow is secured by P only if λ(x) 6 λ(y). ‘λ’ is a
labelling function, responsible for binding subject/ob-
ject of the program to a security class (either statically
or dynamically depending on the application) from
the lattice of security classes as described in Den-
ning’s lattice model (Denning, 1976). ‘6’ is a binary
relation on security classes that specifies permissible
information flows. ‘⊕’ is a binary class-combining
operator evaluates least upper bound (LUB) of two
security classes in the lattice. The above condition
is usually referred to as the Information-flow policy
(IFP). A program is certified for IFP if there are no vi-
olations of the policy during program execution. The
Information Flow Secure policy forms a basis for cer-
tifying programs for security. The crux of certification
lies in assuring that all the information flows over le-
gitimate channels or storage channels follow the spe-
cified flow-policy. The outcome of approaches could
be measured in terms of precision defined below.
Let us suppose that F is the set of possible flows
in an information flow system, and let A be the sub-
set of F authorized by a given flow policy, and let E
be the subset of F “executable” given the flow con-
trol mechanisms in operation. The system is said to
be secure if E ⊆ A; that is all executable flows are
authorized. A secure system is precise if E = A.
The method of binding security classes/labels to
objects plays an important role in the analysis of pro-
grams. Each of the static certification and runtime en-
forcement algorithms proposed in the literature choo-
ses an object labelling method, some of which may
also use the label of the implicit variable, usually re-
ferred to as Program Counter (PC) which may be re-
set after every statement or keeps updating monotoni-
cally. First, let us consider the following three broad
object labelling schemes:
Scheme 1: fixed labels for all the variables,
Scheme 2: labels of all the variables can be modified;
for example, based on the information contained
in them at any given program point, and
Scheme 3: labels of some variables are fixed while
the labels of the other variables could be modified.
In this section, we argue that from the perspective
of capturing the notion of security, (i) Scheme 1 is
inappropriate as it is too stringent, and results in se-
cure programs being incorrectly rejected as insecure,
Static Security Certification of Programs via Dynamic Labelling
235

(ii) Scheme 2 is also inappropriate as it allows all pro-
grams as secure programs, and (iii) Scheme 3 is the
ideal candidate, if the variables whose labels can be
allowed to be modified are carefully chosen.
Majority of literature on language-based security
follows Scheme 1, as it has advantages in certifying
tricky programs such as the one given in Table 1.
Table 1: There is im-
plicit flow from x to
y while there is no
direct flow.
1 void test(int x){
2 int y=0;
3 int z=0;
4 if(x==0)
5 z=1;
6 if(z==0)
7 y=1;
8 }
Table 2: Need
to label local
variables dyn-
amically.
1 void test(){
2 int a;
3 a=x;
4 y=a;
5 a=z;
6 }
As the program in Table 1 executes, the following
information flow is observed: if the value of x is 0,
the value of z becomes 1, and the second if block will
not execute, thus the value of y remains 0. On the
other hand if the value of x is 1, the second if block
executes, and y is initialized to 1. In either cases the
value of y is same as the value of x although there is
no such explicit assignment e.g. x = y. If we consider
the security labels of x and y are x and y and x  y
then this is an example of insecure program as there
is an implicit flow from x to y even though they belong
to different security classes where an explicit flow is
not allowed. Table 3 analyzes two different labelling
approaches i.e. Scheme 1 and Scheme 2 in respect of
the program in Table 1.
However, purely static labelling is too restrictive,
and rejects secure programs as insecure. This is illus-
trated by considering the program fragment shown in
Table 2, where x, y and z are global variables, and a is
a local variable (we do not consider pointer variables).
If the program in Table 2 is analyzed under
Scheme 1, it generates the following set of flow-
constraints to be satisfied for the program to be se-
cure: x 6 a, a 6 y, and z 6 a. These constraints will
be satisfied only if z 6 y, which implies that there is
an information-flow from z to y. However, from an
intuitive perspective, the program never causes an in-
formation flow from z to y, and must be considered se-
cure if x 6 y. Table 4 analyzes two different labelling
approaches i.e. Scheme 1 and Scheme 2 in respect of
the program in Table 2.
From the above examples, it follows that the use of
purely static labelling is too conservative, and misses
several secure programs.
2.1 Refinement Via PC Labels
Information flow is quite tricky to capture, and can
happen even if a statement does not get executed.
Such flows are called “implicit” (Robling Denning,
1982), and are possible due to conditional and itera-
tion statements. To keep track of such impact, the
notion of the program counter (pc) label is introdu-
ced that denotes the sensitivity of the current con-
text. Traditionally, once the control exits the condi-
tional and/or iteration statements, the pc label is reset
to its previous value, thus denoting that the variables
in the condition expression no longer impact the cur-
rent context. Subsequently, a sequential composition
S
1
;S
2
is deemed secure if both S
1
and S
2
are individu-
ally secure.
Examples copy3 and copy4 in (Robling Denning,
1982) have highlighted that certain subtle flows can-
not be captured unless the pc label is updated monoto-
nically, and tracks the influence of all the information
the program has accessed. It was noted that this may
lead to a phenomenon called “label creep” (Sabelfeld
and Myers, 2003) wherein the pc label rises too high
resulting in rejecting any further flows. To avoid label
creeping, the current literature on language-based se-
curity takes the route of resetting pc label after exiting
from a control structure.
2.1.1 Tracking PC Labels(Stefan et al., 2011)
The method described for Haskell envisaged in (Ste-
fan et al., 2011) uses a label for current control wit-
hout reinitializing every time the control exits a state-
ment. A labeled IO Haskell library unit LIO is built to
track a single mutable current label (similar to pc) at
run-time, and allows access to IO operations. The unit
is responsible to ensure that the current label keeps
track of all the observed data, and regulates label mo-
difications. At each computation LIO keeps tracks of
the current label and allows access to IO functionality
e.g., labeled file systems. The current label is evalu-
ated as an upper bound of all the labels observed du-
ring program execution.
2.2 Labelling Schemes: A Summary
Table 5 summarizes possible ways of binding labels
with objects.
Some programs where ignoring the label of pro-
gram point leads to incorrect certification are given
in Tables 6 and 7. Table 6 shows an example with
information leaks due to abnormal termination of a
program. The value of x can be calculated from the
value of sum (maximum possible integer value) and
y on terminating the program due to integer overflow.
SECRYPT 2018 - International Conference on Security and Cryptography
236

Table 3: Analyzing information flow at each line from example in Table 1 according to static and dynamic labelling.
Line No. Static labelling (Scheme 1) Dynamic labelling (Scheme 2)
3 Label of z would be inferred in Label of z is initialized to least
such a way that all the flows to and confidential security class e.g. public (⊥)
4 from z should be secured. If z is As there is a flow from x → z
assigned to x, the flow from z → y z is updated to x such that x 6 z
5 is not permitted.
6 There is no way to label z so that There is a flow from z → y.
all the flows are safe. For this But x cannot flow into y.
7 reason the program is insecure. Hence the program is insecure.
Table 4: Analyzing information flow at each line of example shown in Table 2 according to static and dynamic labelling.
Line No. Flow direction Static labelling (Scheme 1) Dynamic labelling (Scheme 2)
5 Label of a is automatically Label of a is initialized to least
inferred in such a way that all the confidential security class e.g. public ⊥
6 x → a flows to and from a is secure. Label of a is updated to label of
If a is labelled as x ⊕ z due to x i.e. x so that x can flow to a.
explicit flows from x and y to a,
7 a → y the constraint x ⊕ z 6 y will not be Flow is allowed as the constraint
satisfied because z  y. x 6 y is satisfied.
8 z → a Label of a is updated to
As static labelling fails to label the x ⊕ z so that
local variable a, the program is flow is allowed as z 6 x ⊕ z.
insecure. Hence the program is flow-safe.
Table 5: Binding labels with objects for certification.
pc Label→
Labelling↓
Reset Monotonic
Static P
1
P
2
Hybrid P
3
P
4
Table 6: Information-flow through abnormal termination
(cf. Copy6 from (Robling Denning, 1982)).
Program Label constraints
y=0; y = high
int sum=0; x = high
while(true){
sum=sum+x; sum ⊕ x 6 sum sum = x
y=y+1; y ⊕ Low 6 y
}
There is an implicit flow from x to y although the as-
signment to y is conditioned on sum.
A non-terminating flow insecure program is
shown in Table 7. Let us consider the given label of
the global variables x and y are given as x and y such
that x  y. It can be observed that the variable y holds
the value equal to x depending on the termination of
the program.
Although LIO follows the label binding P
2
that
keeps track of program point but the run-time monitor
fails to stop adversary from obtaining the high values
by observing the termination of programs. Later in
Table 7: Information-flow through non-termination (Cf.
Copy5 from (Robling Denning, 1982)).
Program Label constraints
y=0; y = high
while(x==0) x = high
skip;
y=1; y ⊕ Low 6 y
the Section 3 we illustrate examples that manifest P
4
also covers P
2
. Considering all the limitations dis-
cussed above, a compile-time monitor based on the
labelling Scheme 3 and binding mechanism P
4
would
be a better candidate for secure certification of pro-
grams. A comparative study is given in the Section 4
where we categorize the existing prominent IFC tools
and platforms based on the labelling mechanisms.
From the above studies, we can infer:
1. While static labelling has advantages for the secu-
rity certification of programs, over-approximately
annotated static labels of local variables may lead
to imprecision, and adversely impacts the sound-
ness of these approaches.
2. For certifying iterative programs (terminating,
non-terminating, abnormally terminating inclu-
ding exceptions), annotating local variables with
improper static labels, and following the scheme
that resets the label of the program counter, often
miss to capture both the forward label propaga-
Static Security Certification of Programs via Dynamic Labelling
237

tion, and impact on static labels due to repeated
backward information flow and leads to a loss of
precision and soundness.
3. While the certification approach of Denning ge-
nerates the relevant constraints, it fails to assert
the existence of possible labelling for local varia-
bles/objects that satisfy the initial labels of global
variables/objects.
If we can compute labels (or policies) for local va-
riables such that the flow security is satisfied at all
the program points, then we could consider such pro-
grams to be secure. Thus the question will be: is there
a dynamic labelling procedure that realizes the same?
A sound dynamic labelling approach that overcomes
the limitations of the current techniques listed above
shall be presented in Section 3.
3 OUR APPROACH TO
CERTIFICATION
Our approach of certification is based on a hybrid la-
belling of objects in the program, that could possibly
be unrolled a finite number of times. Possibility (or
other wise) of labelling the objects of the program
leads to certification (or other wise) of the program;
the same could be used in the execution monitor for
checking flow security at run-time.
In the following, we describe our Dynamic Label-
ling (DL) algorithm. The algorithm finds its basis in
Denning’s certification semantics.
3.1 Dynamic Labelling Algorithm: DL
Notation: Let G be the set of global variables/objects,
L the set of local variables of a program, (var)(e) the
set of variables appearing in expression e, pc the pro-
gram counter, and λ, λ
0
, λ
1
, ··· the labelling functions
that give the security label/sensitivity-level of varia-
bles and pc.
SV is a function that takes a statement/command
as input, and returns the set of source variables ap-
pearing in it as output. TV is a function that takes
a statement/command as input, and returns the set of
target variables appearing in it as output. DL is a dy-
namic labelling procedure/function that takes a com-
mand, clearance level of the subject executing the pro-
gram, and a labelling function, as inputs, and returns
either a labelling or UNABLE TO LABEL as output.
λ
init
denotes the initial labelling. ∀x ∈ G : λ
init
(x)
is given, ∀x ∈ L : λ
init
(x) = ⊥, and λ
init
(pc) = ⊥,
where ‘⊥’ is the least restrictive security class or pu-
blic. Let P be a given program together with initial
labelling for the global objects. Let s denote the sub-
ject trying to execute the program, and cl denote his
clearance. If DL(P, cl, λ
init
) returns a valid labelling,
then the program preserves information-flow security
when executed by the subject s. If DL(P, cl, λ
init
) re-
turns ‘UNABLE TO LABEL’, then information-flow
security will be violated if the program is executed
by the subject s, and the algorithm exits at that point
without proceeding further.
Algorithm DL is described in Table 8. It is illus-
trated through examples followed by its’ soundness
in the sequel.
Illustrative Examples:
We illustrate the advantages of our dynamic labelling
procedure by analyzing the example programs from
Section 2. Examples clearly highlight the advantages
of the dynamic labelling procedure in capturing sub-
tle information-flows through control flow path, non-
termination / abnormal termination channels etc. For
each example, initial labels of the global variables are
provided. We assume that the subject executing the
program has the highest security label, and thus ig-
nore the clearance field; dynamic labelling is shown
in a tabular form.
We apply the proposed algorithm to the example
shown in Table 2. It can be observed that the algo-
rithm successfully labels the intermediate variable a.
Example 1. Initial labels for global variables:
λ(x) = λ(y) = x
, λ(z) = z
Consider the example shown in Table 6 where x
and y are global variables having labels x and y re-
spectively. At the point y=y+1 the program fails to
satisfy the constraint y ⊕ pc 6 y because the label of
pc is updated to x and x  x. Therefore the algorithm
declares the program as flow-insecure.
The algorithm if applied to the program in Table 7
identifies the flow violation as shown in Table 10: the
label of pc is updated to x while testing the predicate;
detects the flow violation at the statement y=1 because
the constraint pc 6 y does not satisfy. Hence the al-
gorithm fails to proceed further, and declares the pro-
gram as flow-insecure, thus detects the control point
where a certain object can leak information.
Example 2. Global variable(s): x, y; No local varia-
bles.
Initial labels for global variables: λ(x) = x, λ(y) = y
3.2 Soundness of Algorithm DL
In this section, we establish the termination of our
dynamic labelling algorithm, and its soundness w.r.t.
SECRYPT 2018 - International Conference on Security and Cryptography
238

Table 8: Description of Algorithm DL.
1. S : skip:: SV(S)={
/
0}; TV(S)={
/
0}; DL(S, cl, λ) : return λ
2. S : x := e:: SV(S)=var(e); TV(S)={x}; 3. S : if e then S
1
[ else S
2
]::
DL=(S, cl, λ): SV(S)=SV(S
1
) ∪ SV(S
2
) ∪ var(e);
tmp =
L
v∈var(e)∩G
λ(v) TV(S)=TV(S
1
) ∪ TV(S
2
)
if (tmp  cl) then DL(S, cl, λ):
exit ‘UNABLE TO LABEL’ tmp =
L
v∈var(e)∩G
λ(v)
λ
1
= λ if (tmp  cl) then
λ
1
(pc) = λ(pc) ⊕ tmp exit ‘UNABLE TO LABEL’
if x ∈ L : λ
0
= λ
λ
1
(x) = λ(x) ⊕ λ(pc)⊕ tmp λ
0
(pc) = λ(pc) ⊕ tmp
return λ
1
λ
1
= DL(S
1
, cl, λ
0
)
if x ∈ G : λ
2
= DL(S
2
, cl, λ
0
)
if

λ(pc) ⊕ tmp ⊕ cl

6 λ(x)

then λ
3
(pc) = λ
1
(pc) ⊕λ
2
(pc)
return λ
1
∀x ∈ L : λ
3
(x) = λ
1
(x) ⊕ λ
2
(x)
else exit ‘UNABLE TO LABEL’ return λ
3
4. S : while e then S
1
:: 5. S : S
1
;S
2
;::
SV(S)=SV(S
1
) ∪ var(e); SV(S)=SV(S
1
) ∪ SV(S
2
);
TV(S)=TV(S
1
); TV(S)=TV(S
1
) ∪ TV(S
2
);
DL(S, cl, λ): DL(S, cl, λ):
tmp =
L
v∈var(e)∩G
λ(v) return DL(S
2
, cl, DL(S
1
, cl, λ));
if (tmp  cl) then
exit ‘UNABLE TO LABEL’
λ
1
= λ Here, problem of “insecurity” will be
λ
1
(pc) = λ(pc) ⊕ tmp indicated by one of the recusive calls.
λ
2
= DL(S
1
, cl, λ
1
)
if (λ
2
6= λ
1
)
λ
1
= λ
2
λ
2
= DL(while e do S
1
,
cl, λ
1
)
return λ
2
Note that “UNABLE TO LABEL” yields the control point where a certain object
fails to satisfy the information flow policy.
Table 9: DL successfully labels that was no possible by sta-
tic labelling.
Statement pc Label of
Label local variable(a)
⊥ ⊥
int a=x; x x
y=a; x x
a=z; x ⊕ z x ⊕ z
Table 10: DL detects “insecurity” by failing to label a non-
terminating flow.
Statement pc Label
⊥
y=0; ⊥
while x==0 x
skip;
y=1; UNABLE TO LABEL
non-interference.
Clearly, the procedure in Table 8 always termina-
tes and is efficient. In fact, it is linear in the size of the
program. This fact is formally established through the
propositions below.
Proposition 1. DL(S, cl, λ) always terminates for any
program S not containing iteration, any label cl, and
any labelling λ.
Proof. The proof is by structural induction. For the
base case, it is trivial to observe that the proposition
holds for skip, and x := e.
For the inductive step, it is easy to prove that if the
proposition holds for S
1
and S
2
, then it also holds for
if e then S
1
else S
2
, and for S
1
;S
2
.
Proposition 2. For any program S not contai-
ning iteration, any label cl, and any labelling λ,
if DL(S, cl, λ) returns a valid labelling λ
1
, then
λ
1
(pc) = λ(pc)
L
v∈SV (S)∩G
λ(v).
Static Security Certification of Programs via Dynamic Labelling
239

The proof of this proposition is by structural in-
duction and is omitted for brevity.
Proposition 3. DL(while e do S, cl, λ) always
terminates for any program S not containing iteration,
any label cl, and any labelling λ.
Proof. From the definition of DL, we note
that the only case in which the evaluation of
DL(while e do S, cl, λ) does not terminate is
when either the evaluation of DL(S, cl, λ
1
) does not
terminate, or DL(while e do S, cl, •) goes into an
infinite recursion.
The former is impossible due to Proposition 1. Im-
possibility of the latter is shown by considering the
evaluation of DL(while e do S, cl, λ):
1. λ
1
= λ, λ
1
(pc) = λ(pc)
L
v∈var(e)∩G
λ(v)
2. λ
2
= DL(S, cl, λ
1
)
3. If λ
2
= λ
1
the evaluation terminates and there is
nothing to prove. So we assume that λ
2
6= λ
1
.
In this case DL(while e do S, cl, λ
2
) is invoked
which proceeds as follows.
4. λ
3
= λ
2
, λ
3
(pc) = λ
2
(pc)
L
v∈var(e)∩G
λ
2
(v)
5. λ
4
= DL(S, cl, λ
3
)
6. If λ
4
= λ
3
the evaluation terminates and there is
nothing to prove. So we assume that λ
4
6= λ
3
.
In this case DL(while e do S, cl, λ
4
) is invoked
which proceeds as follows.
7. λ
5
= λ
4
, λ
5
(pc) = λ
4
(pc)
L
v∈var(e)∩G
λ
4
(v)
8. λ
6
= DL(S, cl, λ
5
)
We claim that λ
6
= λ
5
. The proof is given below.
1. First iteration: λ
1
(pc) = λ(pc) ⊕
v∈var(e)∩G
λ(v)
λ
2
(pc) = λ
1
(pc) ⊕
v∈SV (S)∩G
λ(v)
= λ(pc) ⊕
v∈var(e)∩G
λ(v) ⊕
v∈SV (S)∩G
λ(v)
= λ(pc) ⊕
v∈(var(e)∪SV(S))∩G
λ(v)
(1)
2. Second iteration:
λ
3
(pc) = λ
2
(pc) ⊕
v∈var(e)∩G
λ(v)
= λ(pc) ⊕
v∈(var(e)∪SV(S))∩G
λ(v)
⊕
v∈var(e)∩G
λ(v)
= λ(pc) ⊕
v∈(var(e)∪SV(S))∩G
λ(v)
(2)
λ
4
(pc) = λ
3
(pc) ⊕
v∈SV (S)∩G
λ(v)
= λ(pc) ⊕
v∈(var(e)∪SV(S))∩G
λ(v)
λ
4
(x) = λ
3
(x) ⊕ λ
3
(pc) ⊕
v∈SV (S)∩G
λ(v)
= λ
3
(x) ⊕ λ
3
(pc)
This is because the label of PC is already
influenced by all the global variables in S.
= λ
2
(x) ⊕ λ(pc) ⊕
v∈(var(e)∪SV(S))∩G
λ(v)
(3)
3. Third iteration:
λ
5
(pc) = λ
4
(pc) ⊕
v∈var(e)∩G
λ(v)
= λ(pc) ⊕
v∈(var(e)∪SV(S))∩G
⊕
v∈var(e)∩G
λ(v)
= λ(pc) ⊕
v∈(var(e)∪SV(S))∩G
λ(v)
λ
5
(x) = λ
4
(x)
= λ
2
(x) ⊕ λ(pc) ⊕
v∈(var(e)∪SV(S))∩G
λ(v)
(4)
λ
6
(pc) = λ
5
(pc) ⊕
v∈SV (S)∩G
λ(v)
= λ(pc) ⊕
v∈(var(e)∪SV(S))∩G
λ(v)
λ
6
(x) = λ
5
(x) ⊕ λ
5
(pc) ⊕
v∈SV (S)∩G
λ(v)
= λ
2
(x) ⊕ λ(pc) ⊕
v∈(var(e)∪SV(S))∩G
λ(v)
(5)
It can be observed that λ
6
= λ
5
. Thus, we can con-
clude that for the iteration statement, the dynamic
labelling procedure terminates after a maximum of
three iterations.
Combining propositions 1 and 3 leads to the fol-
lowing proposition.
Proposition 4. DL(while e do S, cl, λ) always
terminates for any program S, any label cl, and any
labelling λ.
Proposition 4 immediately establishes termination
of DL as formalized below.
Proposition 5. DL(S, cl, λ) always terminates for any
program S, any label cl, and any labelling λ.
Next, we prove some results that highlight the im-
portant characteristics of our dynamic labelling pro-
cedure.
Proposition 6. During the dynamic labelling of any
program S with any clearance cl, i.e. during the eva-
luation of DL(S, cl, λ
init
), λ(pc) 6 cl always holds.
Proof. In the initial state λ
init
(pc) = ⊥ 6 cl. From
the definition of DL, we note that the label of pc gets
updated by taking its LUB with tmp only when tmp 6
cl. Therefore λ(pc) 6 cl always holds due to simple
lattice properties.
Proposition 7. An assignment to a global variable x
is deemed safe by the dynamic labelling algorithm for
a program executing with clearance cl if and only if
cl 6 λ(x).
Proof. (Necessity of cl 6 λ(x)) From the definition
of DL for an assignment statement, it is immediately
clear that if the operation is deemed safe then it must
be the case that cl 6 λ(x).
(Sufficiency of cl 6 λ(x)) Note that we have
λ(pc) 6 cl from Proposition 6, and for the control to
SECRYPT 2018 - International Conference on Security and Cryptography
240

reach the point, we need tmp 6 cl, thus reducing the
check (λ(pc) ⊕tmp ⊕ cl) 6 λ(x) to cl 6 λ(x).
Proposition 8. During the dynamic labelling of any
program S, λ(pc) is monotonically non-decreasing.
The proof of the above is trivially obtained by
structural induction and is omitted for brevity.
Next, we prove a generalization of the result in
Proposition 2.
Proposition 9. For any program S, any label cl, and
any labelling λ, if DL(S, cl, λ) returns a valid label-
ling λ
1
, then λ
1
(pc) = λ(pc)
L
v∈SV (S)∩G
λ(v).
The proof of this proposition is by structural in-
duction and is omitted for brevity.
Proposition 10. During the dynamic labelling of any
program S, for all x ∈ L, λ(x) is monotonically non-
decreasing.
Proof. For x ∈ L, the label of x is updated by the dy-
namic labelling procedure only in the case of expli-
cit assignment. In this case the label of x changes to
λ(x) ⊕ λ(pc) ⊕ tmp. Monotonicity of λ(pc) imme-
diately gives us that λ(x) is also monotonically non-
decreasing.
Proposition 11. During the dynamic labelling of any
program S i.e. DL(S, cl, λ
init
), ∀x ∈ L λ(x) 6 λ(pc)
always holds.
Proof. In the initial state we have λ
init
(x) =
λ
init
(pc) = ⊥. We will show that every time the la-
bel of x is updated, the property holds in the new state
also.
• S :: x := e
λ
1
(x) 6 λ(x) ⊕ λ(pc)⊕ tmp
λ
1
(x) 6 λ(pc) ⊕tmp [ by hypothesis λ(x) 6 λ(pc)]
λ
1
(x) 6 λ
1
(pc)
(6)
• S :: if e then S
1
else S
2
λ
3
(x) 6 λ
1
(x) ⊕ λ
2
(x)
λ
3
(x) 6 λ
1
(pc) ⊕ λ
2
(pc) [ by hypothesis]
λ
3
(x) 6 λ
3
(pc)
(7)
Relation with Non-interference:
In this section, we establish that the dynamic labelling
algorithm is sound w.r.t. non-interference (Volpano
et al., 1996).
A simple example illustrates the relation with non-
interference. Consider the program P
1
: x := y; - where
x, y are global objects, and the labelling λ(y) = l
2
,
λ(x) = l
3
, where l
2
and l
3
come from a total order
l
1
6 l
2
6 l
3
6 l
4
. Consider four subjects s
1
, s
2
, s
3
, and
s
4
, with clearances l
1
, l
2
, l
3
, and l
4
respectively.
P
1
is non-interfering. Dynamic labelling of P
1
succeeds only for subjects s
2
and s
3
. Dynamic label-
ling fails for s
1
because his clearance is below y, and
therefore should not be allowed to access y. Similarly,
dynamic labelling fails for s
4
because his clearance is
above x and therefore should not be allowed to update
x.
In the following, we shall formally establish the
soundness of the dynamic labelling procedure w.r.t.
non-interference. Note that globals are the only ob-
servables in this setting.
Theorem 1 (Soundness). If there exists a subject for
which a program is declared secure by the dynamic
labelling procedure in Table 8, then the program is
non-interfering.
Proof. For reasoning about value based non-
interference, it suffices to work with the last update to
a low labelled variable. From the definition of DL, we
observe that the only place where a global variable
is potentially updated is guarded by the condition
λ(pc) ⊕ tmp ⊕ cl 6 λ(x). In particular, since we are
dealing with λ(x) = low, and the program is declared
secure by the dynamic labelling procedure, we can
immediately infer that λ(pc) = tmp = cl = low. This
guarantees that no high labelled variable could have
been accessed by this time in the execution.
Traditional methods for the security certification
of programs do not consider the subject labels. Let
DL
1
(S, λ) be a modified dynamic labelling algorithm
obtained by ignoring cl from the algorithm given in
Table 8. We now prove that even this algorithm is
sound w.r.t non-interference.
Theorem 2. If a program S is declared secure by the
procedure DL
1
i.e., DL
1
(S, λ) returns a valid label-
ling, then the program is non-interfering.
Proof of this theorem is exactly the same as the
proof of the previous theorem, and is omitted.
Finally, the set of programs declared secure by tra-
ditional certification methods that reset PC and use
static labels for variables (Jif is a prominent repre-
sentative of this class) is incomparable to the set of
programs declared secure by our dynamical labelling
algorithm as shown below.
Proposition 12. There are programs declared secure
by static labelling that cannot be dynamically labelled
(insecure by our definition), and there are programs
declared secure by our approach that static labelling
rejects as insecure.
Static Security Certification of Programs via Dynamic Labelling
241

Table 11: Comparison of IFC tools and platforms.
Tools Labelling Flow Termination
and Platforms mechanism -sensitive -sensitive
Jif P
1
7 7
Paragon P
1
7 7
FlowCaml P
1
7 7
λ
DSec
P
3
3 7
LIO P
2
7 7
λ
LIO
l
P
4
3 3
Aeolus P
1
7 7
DL P
4
3 3
Proof: Programs in Tables 6 and 7 provide an ex-
ample for the former, while the program in Table 2
provides an example for the latter.
4 COMPARISON WITH
RELATED WORK
In this section, we first briefly describe tools and
platforms that enforce rich information flow poli-
cies, and then compare our approach with the exis-
ting approaches. Further, we discuss the applicabi-
lity and limitations for certifying different classes of
programs like (i) termination-sensitive programs, (ii)
concurrent/non-deterministic programs, etc.
Information Flow Tools:
In the last decade a large number of information
flow secure tools have been developed to enforce
rigorous flow security policies through prevailing
programming languages. For example, Jif (Myers
et al., 2001), JOANA (Hammer and Snelting, 2009),
Paragon (Broberg et al., 2013) for Java, FlowFox
(De Groef et al., 2012), JSFlow (Hedin et al., 2014),
IFC4BC (Bichhawat et al., 2014) for JavaScript, Flo-
wCaml (Simonet and Rocquencourt, 2003) for Caml,
λ
DSec
(Zheng and Myers, 2007) for lambda calcu-
lus, LIO (Stefan et al., 2011), HLIO (Buiras et al.,
2015) for Haskell and SPARK flow analysis (Barnes,
2003) for SPARK. Also flow secure platforms for in-
stance, Jif/split (Zdancewic et al., 2002), Asbestos
(Efstathopoulos et al., 2005), HiStar (Zeldovich et al.,
2006), Flume (Krohn et al., 2007), Aeolus (Cheng
et al., 2012) and flow checking systems that imple-
ments sparse information labeling (Austin and Flana-
gan, 2009), permissive-upgrade strategy (Austin and
Flanagan, 2010) and identifies public labels and de-
layed exception (Hritcu et al., 2013) incorporate dif-
ferent label mechanisms shown in Table 11. While
we have omitted some similar prominent platforms
for lack of space, it may be noted that DL realizes
the needed characteristics required for IFC.
The earliest attempt to capture flow-sensitive la-
bels at run-time was observed in the work on λ
DSec
.
This was the first to propose general dynamic la-
bels whose type system was proved to enforce non-
interference. The core language λ
DSec
is a security-
typed lambda calculus that support first-class dyna-
mic labels where labels can be checked and manipula-
ted at run-time. Also labels can be used as a statically
analyzed type annotations. The type system of λ
DSec
prevents illegal information flows and guarantees that
any well-typed program satisfies the non-interference
property. In this language the label of the pc is a
lower bound on the memory effects of the function,
and an upper bound on the pc label of the caller but
unlike DL, pc is not updated dynamically after exe-
cuting each statement hence the language falls in the
category P
3
. The non-interference property discussed
in λ
DSec
is termination-insensitive, and also does not
deal with timing channels. In the following, we pro-
vide a detail discussion on LIO that shares a common
paradigm, and also subsumes the results of λ
Dsec
.
Comparison with (Stefan et al., 2011):
Here, the authors have built a labelled IO Has-
kell library, called LIO, for certifying Haskell pro-
grams. LIO tracks a single mutable current label (like
program-counter) at run-time and allows access to IO
operations. The unit is responsible to ensure that
the current label keeps track of all the observed data
and regulate label modification. A type constructor
Labeled is used to hold the restriction on a value and
is mutable during run-time. At each computation LIO
keeps tracks of current label and allow access to IO
functionality e.g., labeled file systems. Current label
is evaluated as upper bound of all the label observed
during the program execution.
Consider reading a secret reference: a ←
readLIORef secret, where the value “secret” is la-
beled as L
S
. Now to satisfy the information flow
check i.e., (L
S
canFlowTo L
C
) the current label
shall rise to (L
C
join L
S
) to read the secret va-
lue. Note that the value a is not labeled expli-
citly. Now let us take an example that wish to
write the value of an object (a) to an output channel:
writeLIORef output a, where the output channel
is labeled as L
O
(set dynamically according to the
user executing the command). It is only permissible
to modify or write data into the output channel when
(L
C
canFlowTo L
O
) is satisfied. A second label cur-
rent clearance (L
cl
) provides an upper bound to cur-
rent label. Hence, the computation cannot create, read
or write to objects labeled L if L canFlowTo L
cl
==
False.
Although our approach overlaps with that of LIO,
there are subtle differences that are briefed below:
• Unlike statically evaluating the labels in our DL
SECRYPT 2018 - International Conference on Security and Cryptography
242

algorithm, the approach in LIO is based on run-
time floating-label system.
• Compared to DL algorithm, the LIO library
provides IO actions that perform termination-
insensitive flow analysis.
• Due to flow-insensitive labelling LIO does not pro-
vide sensitivity level of each intermediate object
precisely.
We illustrate each of these points in the following.
Comparison of Labelling Mechanism:
The characterization of security labels when associa-
ted with objects is an important aspect of IFC analy-
sis (Hunt and Sands, 2006). Security labels of sub-
jects/objects can be mutable or immutable. Flow-
sensitive IFC monitors allows to change the security
labels over the course of the computation thus incre-
ase the permissiveness, and also alleviate the burden
of explicit label annotations. Note that these moni-
tors perform the flow analysis during execution-time
or compile-time. Mutable label flow analysis during
execution-time helps to precisely determine the flow-
sensitivity of objects at run-time but compile-time
analysis reduces the incident of false-alarms, and al-
lows more programs as secure.
LIO keeps track of a single mutable current
floating-label that is elevated (e.g., from low to high)
at run-time to accommodate reading sensitive data,
hence, LIO is flow-sensitive in current label. Howe-
ver, LIO is flow-insensitive in intermediate object la-
bels. To allow more programs by the run-time moni-
tor, an extension of LIO presented by (Buiras et al.,
2014) that safely manipulates a label on the reference
label. A label on the label describes the confidenti-
ality of the LIO reference label itself. The run-time
monitor upgrades a label of a reference only if that
label on the label can flow to floating-label. Note that
LIO follows the labelling mechanism P
2
whereas the
proposed extension incorporates P
4
. Another exten-
sion of LIO monad i.e., HLIO that provides program-
mers the flexibility to defer flow check of part of the
program to run-time (like LIO) or static-time (unlike
LIO), boosts permissiveness of the monitor.
Algorithm DL, is flow-sensitive in the absence of
method-calls and a compile-time monitor built upon
it would satisfy P
4
, and hence it is more permissive
than the other approaches highlighted above. DL, fol-
lows a hybrid labelling approach where the labels of
global variables are assumed to be fixed and label of
each intermediate object is allowed to vary, thus flow-
sensitive dynamic labels are obtained.
Termination-insensitive Flow Analysis:
Information leak depending on the termination of the
program may remain undetected by the run-time mo-
nitor that extends LIO library unit. A program that ex-
ploits toLabeled function as shown by (Stefan et al.,
2012a) may lead to information leak through termina-
tion channel. toLabeled l m executes the LIO ope-
ration m and encapsulates the returned value with la-
bel l. However the function does not increase the cur-
rent label. Hence one can write an iterative program
that executes a toLabeled function depending on a
secret value or diverge otherwise. Assuming the ini-
tial current label as low, and as it remains unchanged
even after executing toLabeled, an adversary can de-
termine the secret value by observing termination of
the program through standard output.
The DL algorithm keeps track of the sensitive la-
bels observed by the pc at compile-time, therefore a
program that tries to pass termination information to
standard output shall abide by the information flow
policy. Hence the proposed labelling approach per-
forms an exemplary termination-sensitive flow analy-
sis.
Applicability in the Concurrent Context:
As initially LIO was not considered for dynamic flow-
sensitive concurrent settings, an extension is propo-
sed in (Stefan et al., 2012a) that mitigates and elimi-
nates termination and timing channels in concurrent
programs. In that article a separate current label for
each thread is mentioned that keeps track of the sen-
sitivity of the data it has observed, and restrict the lo-
cations to which the thread can write. Hence, while
termination and timing of these threads that may ex-
pose the secret values, the thread requires to raise
it’s current label. This prevents lower security thre-
ads from observing confidential information written
in shared locations. Another extension of LIO propo-
sed by (Buiras et al., 2014) provides the primitive of
automatic upgrade that safely updates flow-sensitive
label references. Both the extensions are shown to be
equally applicable for concurrent context. However,
the extensions may not stop the concurrent programs
(shown in Table 12) from revealing the secret value.
An example of information leakage due to concur-
rent access is presented by (Le Guernic, 2007). The
order of the assignments to x and y variables in VIP
program depends on the secret value of h. The pro-
gram in Newsmonger runs simultaneously and prints
the values of x and y inside an infinite loop that are
shared variables having no explicit label. If News-
monger runs in between any of the assignments that
exist in line 3 and 5 of VIP, it could reveal the value of
h . Assuming the assignments as LIO operations, and
the labels of the current label and h are L
C
and L
h
re-
spectively, the label of y is evaluated as L
C
join L
h
when h is false. Before labelling of x is done by LIO,
Newsmonger might disclose the value in x which in
turn would reveal the secret value h.
Static Security Certification of Programs via Dynamic Labelling
243

Table 12: (a) VIP (left) and (b) Newsmonger (right).
1 x:=0; y:=0
2 if h then
3 x:=1; y:=1;
4 else
5 y:=1; x:=1;
6 end;
1 while true do
2 output x;
3 output y;
4 done;
It can be observed that a run-time monitor may
unroll the threads execution multiple times before
discovering a possible leak. A compile-time monitor
also needs to take care of all possible combinations of
threads executions and label the shared locations ac-
cordingly to identify any information flow violation.
In our approach the DL procedure would identify
the threads responsible to write the shared locations,
and thus can optimize the number of threads to
iterate the algorithm until the label of the locations
converge in the lattice. The proof for the proposition
5 shown in the Section 3.2 for a sequential program
can be extended easily for concurrent context to
show that the procedure requires a finite number of
unrolling rather than a full termination to converge
the labels. We are working on this aspect from a
proof perspective as well as from the point of of view
of language platform.
Determining the Label of Intermediate Variables:
As early as 1975, Dorothy Denning proposed in her
thesis (Denning, 1975) a run-time source-to-source
transformation to guarantee flow security of programs
having selection or iteration statements. Basically, the
method introduces additional code for checking pos-
sible flow violations at run-time. In a sense, her met-
hod, simulates possible information flows for each va-
riable that has to lie between possible greatest and lo-
west levels. As against this, our method succinctly
captures security labels of variables explicitly without
introducing additional code in the program.
5 CONCLUSIONS
We have proposed a certification mechanism that is
built on a hybrid labelling algorithm, DL. The al-
gorithm DL is proved to be sound with respect to
non-interference, and also we have established the
termination of the algorithm. Further, it is shown
to be more security precise as compared to ot-
her approaches, and also succinctly captures labels
for termination-sensitive and progress-sensitive pro-
grams. Further, we have demonstrated that its cha-
racteristics make it possible to label concurrent/non-
deterministic programs to monitor the flow; this pro-
perty seems very useful for certifying security of such
programs. Note that the labelling could be used both
for static certification (that would involve bounded
unrolling of loops) and for run-time monitoring; the
latter will allow the execution only when the flow sa-
tisfies the flow policy or authorized thus enriching the
precision.
We have been working on building a platform for
certifying Python programs. So far, we have succee-
ded in certifying sequential programs including de-
classification rules. We are working on establishing
the termination of the algorithm DL, in the context of
concurrency with or without assertions. As mentio-
ned already, our labelling approach is based on flow
constraints, and hence, can be integrated with any se-
curity model including decentralized models that have
declassification rules.
REFERENCES
Askarov, A. and Sabelfeld, A. (2009). Tight enforcement
of information-release policies for dynamic langua-
ges. In Proc. of 22nd IEEE CSF Symposium, pages
43–59.
Austin, T. H. and Flanagan, C. (2009). Efficient purely-
dynamic information flow analysis. In Proc. of the
ACM SIGPLAN 4th Workshop on PLAS, pages 113–
124.
Austin, T. H. and Flanagan, C. (2010). Permissive dynamic
information flow analysis. In Proc. of the 5th ACM
SIGPLAN Workshop on PLAS, page 3.
Barnes, J. G. P. (2003). High integrity software: the spark
approach to safety and security. Pearson Education.
Bichhawat, A., Rajani, V., Garg, D., and Hammer, C.
(2014). Information flow control in WebKit’s javas-
cript bytecode. In Proc. of Int. Conf. on Principles of
Security and Trust, pages 159–178. Springer.
Broberg, N., van Delft, B., and Sands, D. (2013). Paragon
for practical programming with information-flow con-
trol. In APLAS, pages 217–232. Springer.
Buiras, P., Stefan, D., and Russo, A. (2014). On dynamic
flow-sensitive floating-label systems. In Proc. of IEEE
27th CSF Symposium, pages 65–79.
Buiras, P., Vytiniotis, D., and Russo, A. (2015). HLIO:
Mixing static and dynamic typing for information-
flow control in haskell. In ACM SIGPLAN Notices,
volume 50, pages 289–301. ACM.
Cheng, W., Ports, D. R., Schultz, D. A., Popic, V., Blank-
stein, A., Cowling, J. A., Curtis, D., Shrira, L., and
Liskov, B. (2012). Abstractions for usable information
flow control in aeolus. In USENIX Annual Technical
Conference, pages 139–151.
De Groef, W., Devriese, D., Nikiforakis, N., and Piessens,
F. (2012). FlowFox: a web browser with flexible and
precise information flow control. In Proc. of ACM
CCS, pages 748–759.
SECRYPT 2018 - International Conference on Security and Cryptography
244

Denning, D. E. (1976). A lattice model of secure informa-
tion flow. CACM, 19(5):236–243.
Denning, D. E. and Denning, P. J. (1977). Certification
of programs for secure information flow. CACM,
20(7):504–513.
Denning, D. E. R. (1975). Secure information flow in com-
puter systems.
Efstathopoulos, P., Krohn, M., VanDeBogart, S., Frey, C.,
Ziegler, D., Kohler, E., Mazieres, D., Kaashoek, F.,
and Morris, R. (2005). Labels and event processes in
the asbestos operating system. In Proc. of 20th ACM
SOSP, volume 39, pages 17–30.
Goguen, J. A. and Meseguer, J. (1982). Security policies
and security models. In IEEE Symposium on SP, pa-
ges 11–11.
Hammer, C. and Snelting, G. (2009). Flow-sensitive,
context-sensitive, and object-sensitive information
flow control based on program dependence graphs.
Int. Journal of Information Security, 8(6):399–422.
Hedin, D., Birgisson, A., Bello, L., and Sabelfeld, A.
(2014). JSFlow: Tracking information flow in javas-
cript and its APIs. In Proc. of 29th Annual ACM SAC,
pages 1663–1671.
Hicks, B., King, D., and McDaniel, P. (2007). Jifclipse: de-
velopment tools for security-typed languages. In Proc.
of Workshop on PLAS, pages 1–10.
Hritcu, C., Greenberg, M., Karel, B., Pierce, B. C., and
Morrisett, G. (2013). All your IFCException are be-
long to us. In IEEE Symposium on SP, pages 3–17.
Hunt, S. and Sands, D. (2006). On flow-sensitive security
types. In ACM SIGPLAN Notices, volume 41, pages
79–90.
Krohn, M. N., Yip, A., Brodsky, M. Z., Cliffer, N., Kaas-
hoek, M. F., Kohler, E., and Morris, R. (2007). Infor-
mation flow control for standard OS abstractions. In
Proc. of 21st ACM SOSP, pages 321–334.
Le Guernic, G. (2007). Automaton-based confidentiality
monitoring of concurrent programs. In Proc. of 20th
IEEE CSF Symposium, pages 218–232.
Myers, A. C. (1999). JFlow: Practical mostly-static infor-
mation flow control. In Proc. 26th ACM Symposium
on POPL, pages 228–241.
Myers, A. C. and Liskov, B. (2000). Protecting privacy
using the decentralized label model. ACM TOSEM,
9(4):410–442.
Myers, A. C., Zheng, L., Zdancewic, S., Chong, S., and
Nystrom, N. (2001). Jif: Java information flow.
http://www.cs.cornell.edu/jif.
Robling Denning, D. E. (1982). Cryptography and data
security. Addison-Wesley Longman Publishing Co.
Ryan, P., McLean, J., Millen, J., and Gligor, V. (2001). Non-
interference, who needs it? In Proc. of 14th IEEE CSF
Workshop, pages 237–238.
Sabelfeld, A. and Myers, A. C. (2003). Language-based
information-flow security. IEEE Journal on Selected
Areas in Communications, 21(1):5–19.
Simonet, V. and Rocquencourt, I. (2003). Flow caml in a
nutshell. In Proc. of 1st APPSEM-II workshop, pages
152–165.
Stefan, D., Russo, A., Buiras, P., Levy, A., Mitchell, J. C.,
and Mazi
´
eres, D. (2012a). Addressing covert termi-
nation and timing channels in concurrent information
flow systems. In ACM SIGPLAN Notices, volume 47,
pages 201–214.
Stefan, D., Russo, A., Mitchell, J. C., and Mazi
`
eres, D.
(2011). Flexible dynamic information flow control in
haskell. In ACM Sigplan Notices, volume 46, pages
95–106.
Stefan, D., Russo, A., Mitchell, J. C., and Mazi
`
eres, D.
(2012b). Flexible dynamic information flow control
in the presence of exceptions. CoRR, abs/1207.1457.
Volpano, D. M., Irvine, C. E., and Smith, G. (1996). A
sound type system for secure flow analysis. Journal
of Computer Security, 4(2/3):167–188.
Zdancewic, S., Zheng, L., Nystrom, N., and Myers, A. C.
(2002). Secure program partitioning. ACM Transacti-
ons on Computer Systems (TOCS), 20(3):283–328.
Zeldovich, N., Boyd-Wickizer, S., Kohler, E., and
Mazi
`
eres, D. (2006). Making information flow ex-
plicit in HiStar. In Proc. of 7th Symp. on OSDI, pages
263–278.
Zheng, L. and Myers, A. C. (2007). Dynamic security la-
bels and static information flow control. International
Journal of Information Security, 6(2-3):67–84.
Static Security Certification of Programs via Dynamic Labelling
245