IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 21, NO. 1, JANUARY 2003 1
Language-Based Information-Flow Security
Andrei Sabelfeld and Andrew C. Myers
Abstract— Current standard security practices do not pro-
vide substantial assurance that the end-to-end behavior of a
computing system satisfies important security policies such as
confidentiality. An end-to-end confidentiality policy might assert
that secret input data cannot be inferred by an attacker through
the attacker’s observations of system output; this policy regulates
information flow.
Conventional security mechanisms such as access control
and encryption do not directly address the enforcement of
information-flow policies. Recently, a promising new approach
has been developed: the use of programming-language tech-
niques for specifying and enforcing information-flow policies.
In this article we survey the past three decades of research on
information-flow security, particularly focusing on work that uses
static program analysis to enforce information-flow policies. We
give a structured view of recent work in the area and identify
some important open challenges.
Index Terms—Computer security, confidentiality, information
flow, noninterference, security-type systems, covert channels,
security policies, concurrency.
I. INTRODUCTION
P
ROTECTING the confidentiality of information manip-
ulated by computing systems is a long-standing yet in-
creasingly important problem. There is little assurance that
current computing systems protect data confidentiality and
integrity; existing theoretical frameworks for expressing these
security properties are inadequate, and practical techniques for
enforcing these properties are unsatisfactory. In this article
we discuss language-based techniques—in particular, program
semantics and analysis—for the specification and enforcement
of security policies for data confidentiality.
Language-based mechanisms are especially interesting be-
cause the standard security mechanisms are unsatisfactory
for protecting confidential information in the emerging, large
networked information systems. Military, medical, and finan-
cial information systems, as well as web-based services such
as mail, shopping, and business-to-business transactions are
applications that create serious privacy questions for which
there are no good answers at present.
Analyzing the confidentiality properties of a computing
system is difficult even when insecurity arises only from
unintentional errors in the design or implementation. Addi-
tionally, modern computing systems commonly incorporate
Manuscript received April 15, 2002; revised August 21, 2002. This work
was supported in part by ONR Grant N00014-01-1-0968, in part by NSF
CAREER Award 0133302, and in part by an Alfred P. Sloan Research Fel-
lowship. Any opinions, findings, conclusions, or recommendations contained
in this material are those of the authors and do not necessarily reflect the
views of the Department of the Navy, Office of Naval Research, the National
Science Foundation, or the Alfred P. Sloan Foundation.
A. Sabelfeld and A. C. Myers are with the Computer Science Depart-
ment, Upson Hall, Cornell University, Ithaca, NY 14853, USA (e-mail:
andr{ei, u}@cs.cornell.edu).
untrusted, possibly malicious hosts or code, making assurance
of confidentiality still more difficult.
The standard way to protect confidential data is (discre-
tionary) access control: some privilege is required in order to
access files or objects containing the confidential data. Access
control checks place restrictions on the release of information
but not its propagation. Once information is released from
its container, the accessing program may, through error or
malice, improperly transmit the information in some form. It is
unrealistic to assume that all the programs in a large computing
system are trustworthy; security mechanisms such as signature
verification and antivirus scanning do not provide assurance
that confidentiality is maintained by the checked program. To
ensure that information is used only in accordance with the
relevant confidentiality policies, it is necessary to analyze how
information flows within the using program; because of the
complexity of modern computing systems, a manual analysis
is infeasible.
Belief that a system is secure with respect to confidentiality
should arise from a rigorous analysis showing that the system
as a whole enforces the confidentiality policies of its users.
This analysis must show that information controlled by a con-
fidentiality policy cannot flow to a location where that policy
is violated. The confidentiality policies we wish to enforce
are, thus, information-flow policies and the mechanisms that
enforce them are information-flow controls. Information-flow
policies are a natural way to apply the well-known systems
principle of end-to-end design [1] to the specification of
computer security requirements; therefore, we also consider
them to be specifications of end-to-end security. In a truly
secure system, these confidentiality policies could be precisely
expressed and translated into mechanisms that enforce them.
However, practical methods for controlling information flow
have eluded researchers for some time.
Recently, a promising new approach has been developed by
the authors and others: the use of type systems for information
flow (e.g., [2]–[14]). In a security-typed language, the types
of program variables and expressions are augmented with
annotations that specify policies on the use of the typed data.
These security policies are then enforced by compile-time
type checking, and, thus, add little or no run-time overhead.
Like ordinary type checking, security-type checking is also
inherently compositional: secure subsystems combine to form
a larger secure system as long as the external type signatures
of the subsystems agree. The recent development of semantics-
based security models (i.e., models that formalize security in
terms of program behavior) has provided powerful reasoning
techniques (e.g., [3], [5], [6], [9]–[17]) about the properties
that security-type systems guarantee. These properties increase
security assurance because they are expressed in terms of
end-to-end program behavior and, thus, provide a suitable
2 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 21, NO. 1, JANUARY 2003
vocabulary for end-to-end policies of programs.
The rest of the article is organized as follows. Section II
gives some background on the problem of protecting con-
fidentiality, including why existing security techniques are
unsatisfactory. Section III illustrates the basics of information-
flow techniques by giving examples of a security condition and
a security-type system. Section IV gives a structured overview
of recent work in the field. Section V identifies important
challenges for future work. The article closes in Section VI.
II. B
ACKGROUND
Terminology for security properties relating to confidential-
ity is somewhat inconsistent. This article is about the language-
based specification and enforcement of strong confidentiality
policies based on information flow. In this framework, it is
assumed that computation using confidential information is
possible, and that it is important to prevent the results of
the computation from leaking even partial information about
confidential inputs. This kind of security was described in
Lampson’s seminal article [18] as information confinement,
and has also been known as secrecy. However, both “con-
finement” and “secrecy” have been used to describe related
but weaker security properties. In the context of capability
systems, “confinement” refers to the ability to prevent capabil-
ities (and hence authority) from being transmitted improperly.
Similarly, work on cryptographic protocols often builds on the
Dolev–Yao model [19], where secret information is assumed
to be indivisible and can be leaked only by insertion in its
entirety into a message. Finally, “privacy” is sometimes used
to refer to the protection of the confidentiality of a principal,
but is also sometimes used as a synonym for anonymity.For
clarity we use the term confidentiality. Unless otherwise stated,
the term security refers to confidentiality in this article.
A. Standard Security Mechanisms
Although the difficulty of strongly protecting confidential
information has been known for some time, the research
addressing this problem has had relatively little impact on the
design of commercially available computing systems. These
systems employ security mechanisms such as access control,
capabilities, firewalls, and antivirus software; it is useful to see
how the these standard security mechanisms fall short.
Access control, as embodied in access-control lists [20]
and capabilities [21], [22], is an important part of the current
security infrastructure. For example, a file may be assigned
access-control permissions that prevent users other than its
owner from reading the file; more precisely, these permissions
prevent processes not authorized by the file owner from
reading the file. However, access control does not control how
the data is used after it is read from the file. To soundly enforce
confidentiality using this access-control policy, it is necessary
to grant the file access privilege only to processes that will
not improperly transmit or leak the confidential data—but
these are precisely the processes that obey a much stronger
information-flow policy! Access-control mechanisms cannot
identify these processes; therefore, access control, while use-
ful, cannot substitute for information-flow control.
Other common security enforcement mechanisms such as
firewalls, encryption, and antivirus software are useful for pro-
tecting confidential information. However, these mechanisms
do not provide end-to-end security. For example, a firewall
protects confidential information by preventing communica-
tion with the outside. In practical systems, however, firewalls
permit some communication in both directions (e.g., [23]);
whether this communication violates confidentiality lies out-
side the scope of the firewall mechanism. Similarly, encryption
can be used to secure an information channel so that only
the communicating endpoints have access to the information.
However, this encryption provides no assurance that once the
data is decrypted, the computation at the receiver respects the
confidentiality of the transmitted data. Antivirus software is
based on detecting patterns of previously known malicious
behavior in code and, thus, offers limited protection against
new attacks.
B. Related Work on Language-Based Security
Language-based mechanisms have been used for security
goals other than protecting confidentiality. Perhaps the best-
known language-based security mechanism is the Java run-
time environment, which provides a well-known set of security
mechanisms for Java applets, including the bytecode veri-
fier [24], the sandbox model [25], and stack inspection [26].
All three of these mechanisms are language-based—that is,
enforced through the Java language—although only the byte-
code verifier uses static program analysis. None of these
mechanisms is intended to control information flow, and,
therefore, they are not effective at protecting confidential data.
The bytecode verifier ensures only that applications respect the
Java type system, so that object references cannot be forged
and private fields cannot be directly accessed. Protection of
private fields is important for confidentiality but because it is
static, it is less powerful than access-control mechanisms. The
sandbox model restricts what classes a Java applet can name,
but a malicious applet may violate confidentiality by commu-
nicating with the host from which it was downloaded. Stack
inspection is a dynamic access-control mechanism; although
it helps protect integrity, it does not address confidentiality.
Language-based techniques are also used in other ongoing
security research, where the goal is to use type safety to protect
the machine against subversion by mobile code (e.g., [24],
[27]–[29]), although some more general security policies can
be enforced [30]–[33]. However, none of this language-based
work addresses end-to-end security policies.
C. Covert Channels
Mechanisms for signaling information through a computing
system are known as channels. Channels that exploit a mech-
anism whose primary purpose is not information transfer are
called covert channels [18]; they pose the greatest challenge
in preventing improper information leaks. Covert channels fall
into several categories:
• Implicit flows signal information through the control
structure of a program.
SABELFELD AND MYERS: LANGUAGE-BASED INFORMATION-FLOW SECURITY 3
•
Termination channels signal information through the ter-
mination or nontermination of a computation.
• Timing channels signal information through the time at
which an action occurs rather than through the data
associated with the action. The action may be program
termination; that is, sensitive information might be ob-
tained from the total execution time of a program.
• Probabilistic channels signal information by changing
the probability distribution of observable data. These
channels are dangerous when the attacker can repeatedly
run a computation and observe its stochastic properties.
• Resource exhaustion channels signal information by the
possible exhaustion of a finite, shared resource, such as
memory or disk space.
• Power channels embed information in the power con-
sumed by the computer, assuming that the attacker can
measure this consumption.
Which covert channels are a concern depends on what
attackers can observe of the computing system. For example,
power channels are important for smart cards, because they
must draw their power from the untrusted terminal into which
they are inserted. A program that is secure on an abstract
computer with no power requirements might be part of a
larger, insecure system when it is run on a real computer.
Thus, a computing system can be said to protect confidential
information only with respect to a model of what attackers
and users are able to observe of its execution.
D. Integrity
Biba [34] first observed that integrity can be treated as a
dual to confidentiality, and enforced by controlling information
flows. Confidentiality requires that information be prevented
from flowing to inappropriate destinations; dually, integrity
requires that information be prevented from flowing from
inappropriate sources. Integrity has an important difference
from confidentiality: a computing system can damage integrity
without any interaction with the external world, simply by
computing data incorrectly. Thus, strong enforcement of in-
tegrity requires proving program correctness, often a daunting
obstacle.
E. Mandatory Access Control
Early work on the confidentiality problem, such as that of
Fenton [35], [36] and Bell and LaPadula [37], [38], devel-
oped mandatory access control. In this approach, each data
item is labeled with a corresponding security level that is a
simple confidentiality policy. Information flow is controlled
by augmenting the ordinary computation of data within a
running program with a simultaneous computation of the
corresponding label that controls its future dissemination.
This approach, prescribed by the U.S. Department of Defense
“orange book” [39] for secure systems, has proved to be too
restrictive for general use.
Apart from the obvious computational and storage overhead,
the weakness of purely run-time enforcement mechanisms
is in identifying implicit information flows [40]. Implicit
flows arise from the control structure of the program, as
h := h
mod 2;
l := 0;
if h =1then l := 1
else skip
Fig. 1. An implicit flow.
opposed to explicit flows which are caused by directly passing
confidential data to a public variable. For simplicity, let us
suppose that there are two sensitivity levels, “high” and “low,”
corresponding to greater and lesser confidentiality respectively.
Consider the code of Figure 1, which contains a flow from the
high variable h to the low variable l. This code is insecure,
because it has exactly the same effect as the explicit flow in the
assignment l := h
mod 2. Clearly, the insecurity in this code
arises from the assignment l := 1 in a control context that
is conditioned upon the confidential variable h. Mandatory
access control can catch this assignment by introducing a
process sensitivity label [39] that keeps track of the sensitivity
of the data used to control the process. The assignment to l
is then detected at run time because a high process updates
a low variable. However, consider the case where h =1:no
assignment to l (and hence, no run-time check) occurs, yet the
value of the high variable h can be learned by observing that
l =0holds. In fact, any variable or data structure must be
assumed to contain confidential information if it might have
been modified within the
if statement—or inside any function
called from it. Determining which modifications are possible
requires evaluating all possible execution paths of the program,
which is not feasible at run time.
Confidentiality can be obtained in this example by ensuring
that the process sensitivity label remains high throughout the
rest of the program, effectively treating all values read from
variables as confidential after the
if statement completes. In
this approach the process label must increase monotonically
in sensitivity throughout execution. Any reduction in the
sensitivity of the process label (for example, at the return from
a procedure [41]), creates a possible security violation through
an implicit flow like the one above.
This effect of monotonically increasing labels is known
as label creep, and is a problem for dynamic enforcement
mechanisms. When a variable or field in a data structure
is assigned a value of different sensitivity than the one it
currently contains, it is necessary to apply the maximum of
the two labels to the stored value. Thus, data labels tend to
creep upwards as well. Label creep makes dynamic labeling
systems too restrictive to be generally useful, because the
results of computation tend to be labeled too sensitively for
their intended use [41].
F. Static Information-Flow Control
Denning and Denning [40] first observed that static pro-
gram analysis can also be used to control information flow
with increased precision and low run-time overhead. Static
characterizations of information flow have been implemented
using theorem provers [42], [43]. Information-flow analyses
can also be performed by type checking, which is the focus of
4 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 21, NO. 1, JANUARY 2003
this article. The type-checking approach has been implemented
in the Jif compiler [7], [44].
In the type-checking approach, every program expression
has a security type with two parts: an ordinary type such as
int,
and a label that describes how the value may be used. Unlike
the labels used by mandatory access-control mechanisms,
these labels are completely static: they are not computed at
run time. Because of the way that type checking is carried
out, a label defines an information-flow policy on the use of
the labeled data. Security is enforced by type checking; the
compiler reads a program containing labeled types and in type-
checking the program, ensures that the program cannot contain
improper information flows at run time. The type system
in such a language is a security-type system that enforces
information-flow policies.
The ability to track implicit flows accurately is one of the
major advantages of static enforcement of information-flow
control. To control implicit flows correctly, we introduce a
program-counter label (pc ) that tracks the dependencies of
the program counter. Consider the example of Figure 1 again.
In the branches of the
if statement, the static label pc is
high, capturing the dependency of the program counter on
h. An assignment is considered secure only if the label on the
assigned variable is at least as restrictive as pc. The second
assignment to l (whose label is low ) occurs in a control context
where pc is high, which justifies the rejection of the program
as insecure.
The program-counter label corresponds to the dynamic
process sensitivity label used in mandatory access control, but
there is an important difference: the statement following the
if
statement, if any, can be assigned the same static pc label as
the statement preceding it. This assignment is secure because
arriving at the following statement tells us nothing about h:
the statement is executed regardless of the value of h.
It may seem surprising that static checking can improve
accuracy. The reason is that dynamic enforcement only has
information about a single program execution, but compile-
time type-checking can prove that no possible execution paths
within the
if statement contain insecure assignments. This is
a consequence of the general fact that confidentiality is not a
property of a single execution path, but rather a property of
the set of all executable paths [45], [46].
Notice that if a branch of the
if statement of Figure 1 did
not terminate, an attacker might infer the value of h from
the termination or nontermination of the program. This is an
example of a termination covert channel. We discuss this and
other covert channels in Section IV-C.
G. Noninterference
If a user wishes to keep some data confidential, he or
she might state a policy stipulating that no data visible
to other users is affected by confidential data. This policy
allows programs to manipulate and modify private data, so
long as visible outputs of those programs do not improperly
reveal information about the data. A policy of this sort is a
noninterference policy [47], because it states that confidential
data may not interfere with (affect) public data.
C ::=
skip | var := exp | C
1
; C
2
| if exp then C
1
else C
2
| while exp do C
Fig. 2. Command syntax.
An attacker (or unauthorized user) is assumed to be allowed
to view information that is not confidential (that is public).
The usual method for showing that noninterference holds is
to demonstrate that the attacker cannot observe any difference
between two executions that differ only in their confidential
input [48]. Noninterference can be naturally expressed by
semantic models of program execution. This idea goes back
to Cohen’s early work on strong dependency [49], [50].
McLean [51] argues for noninterference for programs in the
context of trace semantics. However, neither work suggests an
automatic security enforcement mechanism.
III. B
ASICS OF LANGUAGE-BASED INFORMATION FLOW
Recently, techniques for proving that a security-type system
enforces noninterference have been developed for increasingly
complex programming languages. In this section, we introduce
this approach by exploring a simple security-type system that
enforces a noninterference security policy.
Consider the simple imperative language with the syntax
given in Figure 2. This language has
skip, assignment, sequen-
tial composition, conditional, and
while-loop constructs. As
before, we write h and l for typical variables of high and low
confidentiality, respectively. We assume that expressions exp
are formed by applying total arithmetic operations to constants
and variables.
A. Semantics-Based Security
Noninterference for programs essentially means that a vari-
ation of confidential (high) input does not cause a variation of
public (low) output. This intuition can be rigorously formalized
using the machinery of programming-language semantics. We
assume that computation starts in an input state s =(s
h
,s
l
),a
pair consisting of the initial values of h and l, respectively. The
program either terminates in an output state s
=(s
h
,s
l
) with
output values for the high and low variables, or diverges. Thus,
the semantics
C
of a program (command) C is a function
C
: S → S
⊥
(where S
⊥
= S ∪{⊥} and ⊥ /∈ S) that maps
an input state s ∈ S either to an output state
C
s ∈ S,orto
⊥ if the program fails to terminate. The variation of high input
can be described as an equivalence relation =
L
; two inputs are
equivalent whenever they agree on low values (i.e., s =
L
s
iff s
l
= s
l
). The observational power of an attacker can be
characterized by a relation ≈
L
on behaviors (as defined by the
semantics) such that two behaviors are related by ≈
L
iff they
are indistinguishable to the attacker. Relation ≈
L
is said to
reflect the low view of the system. It is often an equivalence
relation but is at least symmetric and reflexive. For a given
semantic model, noninterference is formalized as follows: C
is secure iff
∀s
1
,s
2
∈ S. s
1
=
L
s
2
=⇒
C
s
1
≈
L
C
s
2
(∗)
SABELFELD AND MYERS: LANGUAGE-BASED INFORMATION-FLOW SECURITY 5
[E1–2] exp : high
h/∈ Vars (exp)
exp : low
[C1–3][pc]
skip [pc] h:= exp
exp : low
[low ] l := exp
[C4–5]
[pc] C
1
[pc] C
2
[pc] C
1
; C
2
exp : pc [pc] C
[pc] while exp do C
[C6–7]
exp : pc [pc] C
1
[pc] C
2
[pc ] if exp then C
1
else C
2
[high] C
[low] C
Fig. 3. Security-type system.
which reads “if two input states share the same low values,
then the behaviors of the program executed on these states are
indistinguishable by the attacker.” The particular model of the
observable behavior depends on the desired security property.
For example, in our language we may set s ≈
L
s
iff s, s
∈
S implies s =
L
s
. Under this assumption, condition (∗)
corresponds to the absence of strong dependency [49], [50] of
the variable h on the variable l. According to such a condition,
the program h := l+4 is secure because the low output (which
is the same as low input) is unaffected by changes to the high
input. The program (
if l =5then h := h +1else l := l +1)
is also secure because the final values of l only depend
on the initial value of l. However, the programs l := h
and (
if h =3then l := 5 else skip) are clearly insecure: for
example, taking 2 and 3 as initial high values gives different
final values for l. For the former program with 0 as the initial
value of l we have (2, 0) =
L
(3, 0),but
l := h
(2, 0) =
(2, 2) ≈
L
(3, 3) =
l := h
(3, 0).
B. A Security-Type System
A security-type system is a collection of typing rules that
describe what security type is assigned to a program (or ex-
pression), based on the types of subprograms (subexpressions).
We write exp : τ to mean that the expression exp has type
τ according to the typing rules. This assertion is known as
a typing judgment. Similarly, the judgment [pc ] C means
that the program C is typable in the security context pc.For
our purposes, the security context is just the program counter
label pc (cf. Section II-F).
Figure 3 presents the typing rules for our simple language.
(This system is, in fact, equivalent to a type system by Volpano
et al. [3].) Expression types and security contexts can be either
high or low . According to the rules [E1–2], any expression
(including constants, the variable h, and even l) can have type
high; however, an expression can have type low only if it has
no occurrences of h.
Consider the rules [C1–7]. The commands
skip and h :=
exp are typable in any context. The command l := exp is
only typable if exp has type low . This prevents explicit flows.
Notice that l := exp is only typable in the low context which,
in combination with the rest of the (purely compositional)
rules, disallows implicit flows. Indeed, notice that [high] C
for some command C ensures that there are no assignments to
low variables in C. This justifies the requirement of the rules
[C5–6] that given an
if (loop) with a high guard, the branches
(loop body) must be typable in a high context. Let us refer
to loops with a high guard as high loops, and to conditionals
with a high condition as high conditionals. The rule [C7] is
a subsumption rule. It guarantees that if a program is typable
in a high context then it is also typable in a low context. This
rule allows us to reset the program counter to low after a high
conditional or a loop, avoiding one source of label creep (cf.
Sections II-E and II-F).
Examples of typed programs are [low ] h := l+4; l := l−5
and [high ]
if h =1then h := h +4 else skip. As expected,
the example programs with explicit and implicit insecure flows
l := h and
if h =1then l := 1 else skip are not typable.
IV. T
RENDS IN LANGUAGE-BASED INFORMATION FLOW
We have considered succinct examples of how to express a
noninterference-style security policy using low-view relations
and a static certification-style security analysis using a type
system. However, the true value of these two representa-
tions lies in their connection. Indeed, the ultimate goal for
formalizing confidentiality properties is to have tools that
are not only expressive but also ensure rigorous end-to-end
security policies. While work on information flow prior to the
mid-nineties typically handled either policies or analyses in
separation, Volpano et al. [3] were the first to establish an
explicit connection. They cast a Denning-style analysis as a
type system similar to Figure 3 and showed that if a program
is typable then it is secure according to condition (∗ ). This
result improves security assurance because it is based on an
extensional security definition. Such a definition is expressed
by the low view under a standard semantic model as opposed
to the ad-hoc security semantics (or no security semantics at
all) underlying previous approaches (e.g., [2], [52]–[61]).
We identify four directions of research in language-based
security that branch off from this meeting point of noninter-
ference and static certification: (i) enriching the expressiveness
of the underlying programming language, (ii) exploring the
impact of concurrency on security, (iii) analyzing covert
channels, and (iv) refining security policies. In the rest of
this section, we sketch recent work in these directions. The
diagram in Figure 4 illustrates the structure of current work
and is intended to serve as a road map for the interested reader
to follow the evolution described (recommended references are
provided in the diagram).
A. Language Expressiveness
A major line of research in information flow pursues the
goal of accommodating the increased expressiveness of mod-
ern programming languages. We concentrate on progress on
procedures, functions, exceptions, and objects.
Procedures: Volpano and Smith [63] give a type system
for a language with first-order procedures and prove that it
guarantees noninterference. The type system relies heavily on
polymorphism, a well-studied concept in type systems. Poly-
morphism means that the type of commands or expressions
may be generic, i.e., may depend on the context. For example,
procedures may have polymorphic security types so that their
