Observational Determinism for Concurrent Program Security

University of Pennsylvania ScholarlyCommons

Departmental Papers (CIS) Department of Computer & Information Science

June 2003

Stephan A. Zdancewic University of Pennsylvania, [email protected]

Andrew C. Myers Cornell University

Follow this and additional works at: https://repository.upenn.edu/cis_papers

Recommended Citation Stephan A. Zdancewic and Andrew C. Myers, "Observational Determinism for Concurrent Program Security", . June 2003.

Copyright 2003 IEEE. Reprinted from Proceedings of the 16th IEEE Computer Security Foundations Workshop (CSFW 2003) pages 29-43. Publisher URL: http://ieeexplore.ieee.org/xpl/tocresult.jsp?isNumber=27273

This material is posted here with permission of the IEEE. Such permission of the IEEE does not in any way imply IEEE endorsement of any of the University of Pennsylvania's products or services. Internal or personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from the IEEE by writing to [email protected]. By choosing to view this document, you agree to all provisions of the copyright laws protecting it.

This paper is posted at ScholarlyCommons. https://repository.upenn.edu/cis_papers/53 For more information, please contact [email protected]. Observational Determinism for Concurrent Program Security

Abstract Noninterference is a property of sequential programs that is useful for expressing security policies for data confidentiality and integrity. However, extending noninterference to concurrent programs has proved problematic. In this paper we present a relatively expressive secure concurrent language. This language, based on existing concurrent calculi, provides first-class channels, higher-order functions, and an unbounded number of threads. Well-typed programs obey a generalization of noninterference that ensures immunity to internal timing attacks and to attacks that exploit information about the thread scheduler. Elimination of these refinement attacks is possible because the enforced security property extends noninterference with observational determinism. Although the security property is strong, it also avoids some of the restrictiveness imposed on previous security-typed concurrent languages.

Comments Copyright 2003 IEEE. Reprinted from Proceedings of the 16th IEEE Computer Security Foundations Workshop (CSFW 2003) pages 29-43. Publisher URL: http://ieeexplore.ieee.org/xpl/tocresult.jsp?isNumber=27273

This conference paper is available at ScholarlyCommons: https://repository.upenn.edu/cis_papers/53 Observational Determinism for Concurrent Program Security

Steve Zdancewic Andrew C. Myers Department of Computer and Information Science Computer Science Department University of Pennsylvania Cornell University [email protected] [email protected]

Abstract This paper makes two contributions. First, it presents a definition of information-flow security that is appropriate for Noninterference is a property of sequential programs that concurrent systems. Second, it describes a simple but ex- is useful for expressing security policies for data confiden- pressive concurrent language with a type system that prov- tiality and integrity. However, extending noninterference to ably enforces security. concurrent programs has proved problematic. In this pa- Notions of secure information flow are usually based on per we present a relatively expressive secure concurrent lan- noninterference [15], a property only defined for determin- guage. This language, based on existing concurrent calculi, istic systems. Intuitively, noninterference requires that the provides first-class channels, higher-order functions, and an publicly visible results of a computation do not depend on unbounded number of threads. Well-typed programs obey a confidential (or secret) information. Generalizing noninter- generalization of noninterference that ensures immunity to ference to concurrent languages is problematic because these internal timing attacks and to attacks that exploit informa- languages are naturally nondeterministic: the order of execution about the thread scheduler. Elimination of these refine- tion of concurrent threads is not specified by the language se- ment attacks is possible because the enforced security prop- mantics. Although this nondeterminism permits a variety of erty extends noninterference with observational determin- thread scheduler implementations, it also leads to refinement ism. Although the security property is strong, it also avoids attacks in which information is leaked through resolution of some of the restrictiveness imposed on previous security- nondeterministic choices (in this case, scheduler choices). typed concurrent languages. These attacks often exploit timing flows, covert channels that have long been considered difficult to control [20]. Several recent papers have presented type systems for se- 1 Introduction cure information flow in concurrent languages [43, 38, 41, 5, 19, 29, 36]. The type systems of these languages enforce Type systems for tracking information flow within programs secure information flow; but most of these type systems are are an attractive way to enforce security properties such as so restrictive that programming becomes impractical.

data conﬁdentiality and integrity. Recent work has proposed The secure concurrent language presented in this paper, ÈÊ

a number of security-typed languages whose type systems ÈÊ

, addresses both of these limitations. has been

Ë Ë statically check information ﬂow, ranging from simple cal- proved to enforce a generalization of noninterference for culi [28, 45, 17, 1, 38, 49, 41, 19, 18] to full-featured lan- concurrent systems, based on low-security observational de- guages [27, 50, 30, 4]. Many systems for which informa- terminism. Much of the restrictiveness of prior security type tion security is important are concurrent—for example, web systems for concurrent languages arises from the desire to servers, databases, operating systems—yet the problem of control timing channels; we show that some restrictiveness checking information ﬂow in concurrent programming lan- can be avoided by distinguishing different kinds of timing guages has not yet received a satisfactory solution. channels. This approach opens up a trade-off between the This research was supported in part by DARPA Contract F30602-99-1- observational powers of an attacker and the restrictiveness 0533, monitored by USAF Rome Laboratory, by ONR Grant N00014-01-1- of the enforcement mechanism. In some situations, the more 0968, by NSF CAREER Award 0133302, by NSF Grant 0208642, and by restrictive model of the attacker may be warranted, but in a Sloan Research Fellowship. The U.S. Government is authorized to repro- other cases, the less restrictive model is acceptable. duce and distribute reprints for Government purposes, notwithstanding any

copyright annotation thereon. The views and conclusions contained herein The concurrency features in most previous secure lan- ÈÊ

are those of the authors and should not be interpreted as necessarily repre- guages have been limited. By contrast, provides fairly Ë senting the ofﬁcial policies or endorsement, either expressed or implied, of general support for concurrency: it allows an arbitrary num- the Defense Advanced Research Projects Agency (DARPA), the Air Force ber of threads, it supports both message-passing and shared- Research Laboratory, or the U.S. Government.

memory styles of programming, and communication chan- 2.1 Noninterference and nondeterminism ÈÊ

nels are themselves ﬁrst-class values. is not intended

Suppose that we have a low-equivalence relation that re-

to serve as a user-level programming language (its syntax ¼ lates two program expressions and if they differ only in and type system are too unwieldy). Instead, it is intended

high-security input data. Here (“zeta”) is a label that de- to serve as a model language for studying information ﬂow ﬁnes “high-security”: high-security data is any whose label

and concurrency; nevertheless, using these constructs, one

Ú does not satisfy . The low observer (attacker) can see can encode (via CPS translation) other security-typed lan-

only data protected by .

guages [49].

Ð For example, consider pairs ,where ranges over The approach taken here is to factor the information se-

some high-security data and Ð ranges over low-security data. curity analysis into two pieces: a type system that elimi- An observer with low-security access (only permitted to see

nates both explicit and implicit storage channels, and a race-

ØØ Ø ÛÒ ¿ the Ð component) can see that the pairs

freedom analysis that eliminates timing channels. Factoring

Ó ÒÓØ ØØ ¿ and are different (because ), but

the security analysis makes both the information-ﬂow anal-

ØØ Ø ÛÒ ¿ will be unable to distinguish the pairs

ysis and its proof of correctness more modular. In addition,

Ó ÒÓØ ØØ ¿ and .Wehave:

any improvements in the accuracy of alias analysis (used to

ØØ Ø ÛÒ ¿ Ó ÒÓØ ØØ ¿

detect races) lead directly to improvements in the security

ØØ Ø ÛÒ ¿ Ó ÒÓØ ØØ

analysis. This paper focuses mainly on the type system for explicit information ﬂows, but race freedom is discussed in Section 4.3. Noninterference says that this equivalence relation also The remainder of this paper is structured as follows. Sec- captures the distinctions that can be made by observing the tions 2 and 3 present and argue for our deﬁnition of in- execution of the two expressions; an observer able to see only formation security and also informally describes our con- low-security data learns nothing about high-security inputs

current programming model and its security implications. by watching the program execute. Suppose we have an eval-

ÈÊ

· Ú uation relation . Evaluations of two expressions will be

Section 4 gives the formal deﬁnition of . Section 5 Ë

states our soundness results, including the security theorem. indistinguishable as long as they produce indistinguishable

(Full proofs are available in the dissertation of the ﬁrst au- results: If ,then

¼ ¼

thor [48].) Section 6 covers related work, and the paper con- ¼

´ · Ú · Ú µ µ Ú Ú

(1)

cludes in Section 7.

¼ Ú

Note that values Ú and need not be strictly equal. The 2 Security model equivalence relation on values captures the idea that the low-security observer may be unable to see certain parts of Information security is fundamentally connected to the abil- the program output—it relates any two values whose differ- ity of an observer to distinguish different program execu- ences are not observable by the low observer. tions. Our primary concern is confidentiality. An attacker This definition of security is appealing, although it does must be prevented from distinguishing two program execu- permit high-security information to leak through termination tions that differ only in their confidential inputs, because the behavior. Because termination behavior communicates an attacker might otherwise learn something about the inputs. average of one bit of information in an information-theoretic As usual, we assume that there is a lattice Ä of security sense, we follow common practice by ignoring this covert labels [7, 11]. Lattice elements describe restrictions on the channel [8, 45, 17, 27]. propagation of the information they label; labels higher in This definition does not apply straightforwardly to con- the lattice describe data whose use is more restricted. For current languages. First, the idea that a program termi- confidentiality, labels higher in the lattice describe more con- nates with a single result is less appropriate for a concurrent fidential data whose dissemination should be restricted. In language, where programs may produce observable effects this paper we will leave the lattice abstract; however, it is while continuing to run. This can be addressed by describ-

often useful to think about the simple two-point lattice con- ing the observations about program execution as a ﬁnite or

À Ä Ú À taining just the elements Ä (low) and (high), where

inﬁnite event trace. Suppose that a machine conﬁguration Ñ

Ú Ä

but À

Å Å

consists of a pair where is the state of the memory

The terminology “ ½ is protected by ”isusedtoindicate

Ñ · Ì

and is the executing program. The statement means

Ú ¾ that ½ —intuitively it is secure to treat data with label

that the conﬁguration Ñ may produce the execution trace

¾ ½ as though it has label because the latter label imposes

Ì . For the language deﬁned in this paper, the event trace

more restrictions on how the data is used. The terms “high-

Å Å Å

½ ¾ consists of the sequence of memory states ¼ security” and “low-security” describe data whose labels are that occur as the program executes. relatively high or low in the lattice, respectively. A second, more signiﬁcant difﬁculty with concurrent lan-

guages is nondeterminism; there may be many traces Ì such

· Ì that Ñ . For example, the language presented below has a nondeterministic operational semantics that allows any

Ð× possible interleaving of the evaluations of two parallel pro- assignment Ð might happen to fall on the same

cesses. Informally, there are two rules for evaluating an ex- cache line as a piece of data used by another apparently se-

¾ pression ½ where the symbol represents parallel com- cure program running on the same system. If accesses to 1

position: this other data are conditioned on conﬁdential information,

¼ ¼ ¼ ¼

Ð Ð×

Å Å Å Å

it could make the assignment more likely to

¾ ½

½ ¾

¼ ¼ ¼

¼ come last, winning the write–write race. Thus, an attacker

Å Å Å Å

½ ¾ ¾ ½ ¾ ½ ¾ ½ might learn about conﬁdential data by introducing such pro- The thread scheduler resolves this nondeterminism by grams into a running system. Attacks of this sort have been choosing a thread to run at each execution step. demonstrated [42]. A standard way to handle nondeterminism is a possibilistic generalization of noninterference in which the computa- 2.2 Internal vs. external timing tions of two expressions are considered indistinguishable as long as every possible computation of one expression is pos- Many previous security-typed language approaches for con-

current programs [43, 41, 19, 5, 36] aim to prevent high-

Ñ Ñ

¾ sible for the other expression as well [23]; that is, ½ must imply: security information from affecting the termination behavior

and timing behavior of a program. This decision strengthens

Ì Ñ · Ì µ Ì Ñ · Ì Ì Ì

½ ½ ¾ ¾ ¾ ½ ¾ ½ possibilistic noninterference by considering execution time

(2)

Ì Ñ · Ì µ Ì Ñ · Ì Ì Ì

¾ ¾ ½ ½ ½ ½ ¾ ¾ to be observable by the low-security observer. Conﬁdential information thus cannot be encoded in the execution time of If the evaluation relation is deterministic, this security one thread and then transferred to a second thread, as in the condition is noninterference. Importantly, it can be proved in following example that exploits thread timing behavior:

essentially the same way as noninterference. One common

ØÖÙ

technique is to show that each step of computation preserves Ü (B)

Ø Ò ÐÝ´½¼¼µ Ð× × Ô Ü Ð×µ

the low-level equivalence between conﬁgurations [15, 45]. ´

´ÐÝ´¼µ Ð Ü ºººµ However, a system that satisﬁes the possibilistic security

condition may have a reﬁnement that does not. As a result, ØÖÙ This program initializes variable Ü to and then spawns

an observer may be able to distinguish two such programs Ð× two threads. The ﬁrst thread assigns Ü the value either by comparing the probabilities of possible executions. For immediately or after a delay. The second thread waits long example, consider this program:

enough that the assignment to Ü is likely to have occurred

Ð ØÖÙ Ð Ð× Ð

Ð Ü (A) when is false; this thread then assigns the value of .

Depending on the thread scheduler, this program can reliably

Here the boolean variables Ð and are low- and high-security Ð locations respectively. This program is secure if the low copy the contents of into the variable —an information observer cannot distinguish between the following two pro- leak. Its bandwidth can be increased by placing the code grams: inside a loop.

If program execution time is considered low-observable,

ØÖÙ Ð Ð× Ð ØÖÙ

Ð (A1) information ﬂow control requires that the execution time of

ØÖÙ Ð Ð× Ð Ð× Ð (A2) low-equivalent programs be equal. Because proving state- Suppose that the low observer is unable to distinguish two ments about execution time is difﬁcult, the type systems pro-

traces if their ﬁnal memories have the same values in loca- posed to enforce this security condition have tended to be Ð

tion Ð. In both programs the location may end with the very restrictive. For example, these type systems have usu- Ð× contents ØÖÙ or , so the possible low observations of ally ruled out programs like the following, because its run- the two programs are identical. However, an attacker may ning time depends on high-security information:

be able to infer some information about the initial value of

ØÖÙ Ü (C)

. For example, the thread scheduler may tend to run the ﬁ-

Ø Ò Ð Ý´½¼¼µ Ð× ×Ô Ü Ð×µ

nal expression of the three last, so that the second program ´

usually has the effect Ð . If the scheduler randomly A related way to treat timing channels is to pad code to

chooses ready threads to execute, Ð will be more likely to eliminate them [3, 36], for example by ensuring that the same

contain than . In general, if the distribution of the ﬁnal

time is taken by both branches of an . However, this ap-

values of Ð is different in the two programs, it is undoubtedly proach does not easily handle loops, recursive functions, or

because the assignment Ð is leaking information about instruction-cache effects. via (perhaps probabilistic) reﬁnement of thread scheduler Here we have taken a different approach, drawing a dis-

nondeterminism. tinction between the internally and externally observable

ØÖÙ Ð Ð×µ Even the simple program ´Ð timing behavior of programs. External observations are might be used to violate conﬁdentiality, despite not men- those made by an observer outside the system, timing the

tioning high-security data. For example, the code for the program with mechanisms external to the computing sys- Ê 1 È

The actual operational semantics of is given in Figure 3. tem. Internal observations are those made by other programs Ë

3 Proceedings of the 16th IEEE Computer Security Foundations Workshop (CSFW’03) 1063-6900/03 $17.00 © 2003 IEEE running on the same system. In principle, internal observa- though the ordering of these writes is nondeterministic. Dis- tions are more easily controlled because other programs can allowing races reduces the expressiveness of the language, be subjected to a validation process before being allowed to but because races are difﬁcult to reason about, programmers run. Typically, internal observations also offer greater po- rarely use them intentionally; races are usually bugs. tential for high-bandwidth information transfer, so they may Making programs race-free weakens the ability of a also be more important to control. In this work, the focus is thread to observe the behavior of other threads. The observa- on controlling information ﬂows that are internal to the sys- tional powers of the low observer are weakened correspond-

tem. Because there are many external ﬂows, most of which ingly. This weakening is expressed formally in the relation

Ì Ì

are difﬁcult to control (e.g., conversation between users of that captures when the low observer is able to dis-

¼ Ì the system), and other techniques that can be applied to con- tinguish two traces. Two traces Ì and are related if they trolling them (e.g., auditing, dynamically padding total exe- are equivalent up to stuttering and preﬁxing at every memory cution time), this decision seems reasonable. location, considered independently of other locations.

The beneﬁcial effect of this decision is that example (C) is To be more precise, let Å , a memory, be a ﬁnite map

Ú Å ´Äµ

considered secure because its timing channels are only exter- from locations Ä to values .Then is the contents of

Ì ´Äµ Ì

nal; example (B) is considered insecure because it contains location Ä.Let be the projection of the trace onto a

Ä Ì Å Å Å

½ ¾

an internal timing channel made observable by a race. single memory location ;thatis,if ¼

Ì ´Äµ Å ´ÄµÅ ´ÄµÅ ´Äµ

½ ¾

then ¼ . A sequence of

Ú Ú Ú

½ ¾

2.3 Low-security observational determinism values ¼ is related to another sequence of val-

¼ ¼ ¼ ¼

Ú Ú Ú Ú Ú

ues if for all up to the length of the

¼ ½ ¾

The weaknesses of possibilistic security conditions (e.g., (2))

Ì Ì Ä Ì ´Äµ

led McLean [24] and Roscoe [32] to propose that noninter- shorter sequence. Then if for all locations ,

´Äµ ference be generalized to nondeterministic systems as low- is equivalent up to stuttering to Ì ,orviceversa. security observational determinism. Low-security observa- Combining this deﬁnition of trace equivalence with obser- tional determinism is essentially noninterference as given vational determinism (3) yields a new security condition that above (1), but applied to a nondeterministic system. In our allows high-security information to affect the external termi- framework the observational determinism can be expressed nation and timing behavior of a program, while preventing straightforwardly. Similarly to noninterference, we have two any effect on internal termination and timing behavior.

¼ Two aspects of this deﬁnition merit discussion. First, al- Ñ arbitrary initial conﬁgurations Ñ and that the low ob-

¼ lowing one sequence to be a preﬁx of the other permits an

Ñ Ñ

server cannot distinguish ( ). To avoid information

¼ external nontermination channel that leaks one bit of infor- Ì ﬂows, they must produce indistinguishable traces Ì and :

mation, but removes the obligation to prove program ter-

¼ ¼ ¼

mination. However, this decision implies that the re-

´Ñ · Ì Ñ · Ì µ µ Ì Ì

(3) lation on traces is not an equivalence relation (transitivity

Thus, to a low-level observer who is unable to distinguish

Ì Ú Ú

¼ ½ fails). To see why, consider the three traces ½ ,

states that differ only in high-security components, a system

Ì Ú Ú Ú Ì Ú Ú Ú Ì Ì

¼ ½ ¾ ¿ ¼ ½ ¿ ¾ ½ ¾ , ,wehave and

satisfying this condition appears deterministic.

Ì Ì Ì Ì

¿ ¾ ¿ ½ but . Consequently, we prove the secu-

2.4 Race freedom rity property in terms of a more primitive simulation relation º

(defined in Section 5.3) that is transitive. To obtain deterministic results from the low-security view- Second, considering each memory location independently point, it is not necessary that evaluation itself be determinis- is justified because internal observations of the two locations tic, which is fortunate because nondeterminism is important. can only observe the relative ordering of their updates by Nondeterministic evaluation allows thread scheduler behav- using code that contains a race—and programs containing ior to depend on aspects of the run-time system not under races are disallowed. By requiring only per-location order- the programmer’s control: for instance, the operating sys- ing of memory operations, this definition avoids the restric- tem, the available resources, or the presence of other threads. tiveness incurred by timing-sensitive definitions of security. The problem is how to permit useful nondeterminism with- out creating security holes. Our insight is that requiring race freedom is a solution 3 Synchronization mechanisms to this problem. To be considered secure, a program must The previous section presents a new security condition for enforce an ordering on any two accesses to the same memory concurrent imperative programming languages. A concur- location, when at least one of the accesses is a write. This rent language can be made more expressive by exploiting the

ordering ensures that the sequence of operations performed added ﬂexibility in the condition. This section and the next

ÈÊ

present such a language, called .

at a single memory location is deterministic. Ë Race freedom rules out insecure programs like example The race freedom requirement of the security deﬁnition

(A) because it has a write–write race to the location Ð.How- implies that threads cannot asynchronously communicate

ÈÊ

ØÖÙ Ð ØÖÙµ

´Ð through shared memory. Consequently, uses message

½ ¾

ever, the program is consid- Ë ered secure because it writes to two different locations, even passing for interthread communication, and the communica-

4 Proceedings of the 16th IEEE Computer Security Foundations Workshop (CSFW’03) 1063-6900/03 $17.00 © 2003 IEEE tion is regulated to prevent illegal information ﬂows. Also, Linear handlers are guaranteed to be invoked exactly once

because the security deﬁnition relies on sequencing writes unless the computation diverges. Consequently, no informa-

ÈÊ

to memory, needs a thread synchronization mecha- tion is transmitted by the fact that the linear handler is run. Ë nism. Despite its importance for practical concurrent pro- Furthermore, linear handlers cannot create nondeterminism gramming and impact on information-ﬂow properties, syn- because there is never any send contention. These observa-

chronization has only recently been studied in the context of tions enable more precise information-ﬂow checking. ÈÊ

information security [19, 30, 18]. provides a thread- Channel arguments are given a security label that restricts Ë synchronization mechanism based on the same abstraction it what data may be sent on them. This suggests an alternate uses for message passing. formulation of the security condition of Section 2.3: a program could be equipped with a distinguished output channel 3.1 Message passing that accepts only low values, and we could require that the To support both thread synchronization and communication, sequence of values sent on the output channel is determinis-

ÈÊ tic. A distinguished input channel would also be required to

uses message passing. The programming model of Ë

ÈÊ allow the program context to acknowledge the output. The

is based on the join calculus [13], which supports ﬁrst- Ë

ÈÊ difference between the two approaches is not large, because

class channels; extends it with linear channels and Ë linear handlers. This linear synchronization mechanism pro- memory locations can be viewed as external processes that vides additional structure that allows the type system to more receive messages at every write.

accurately describe synchronization information ﬂows. Ê

È 3.2 Synchronization

The notation for sending a value on a channel is

ÈÊ

´Ú µ

. Messages may contain no data, in which case the send So far, has not addressed the issue of synchronization Ë

is written ´µ, or they may contain multiple values, in which between concurrent threads. Rather than directly incorpo-

´Ú ¸ººº¸Ú µ Ò case the send is written ½ . A send on a channel rating mutexes or semaphores as primitives, we adopt join

may cause the activation of a corresponding message handler patterns as found in the join calculus [13]. With this design,

Üµ £ Ð Ü (or simply handler), for example: ´ handlers may block waiting for messages on multiple chan-

When a message is sent on channel , the handler triggers, nels, permitting synchronization on several threads of execu-

creating a new thread to execute Ð with the message tion. For example, the following handler waits for messages

ÒÔÙØ ÒÔÙØ ¾

contents bound to the variable . The message is consumed on channels ½ and before starting the thread Þººº by the handler. Handlers may invoke their own channel, al- “ ÐØ ”.

lowing encoding of loops and recursive functions.

ÒÔÙØ ´Üµ ÒÔÙØ ´Ý µ £ Ð Ø Þ Ü · Ý Ò ÓÙØÔÙØ´Þµ

½ ¾

Handler deﬁnitions are introduced via ÐØ-syntax. For ÈÊ

example, a program described above is:

Ë If some of the channels in the join pattern never receive a

´Üµ £ Ð Ü Ò ´Øµ ÐØ message, the handler never triggers. Multiple threads might attempt to send messages on a sin- This approach simpliﬁes reasoning about synchroniza- gle channel concurrently, creating send contention and pos- tion. Unlike mutexes or semaphores, which may be used sibly race conditions. Lexical scoping of channel names anywhere within a program, join patterns limit synchronization to points at which messages are received. makes it impossible to introduce receive contention,inwhich 2

multiple handlers vie for a message. Despite this abstraction , join patterns support a range Ê È of useful synchronization idioms [13]. In particular, they

In channels are ﬁrst-class and may be passed as val- Ë

ues in the messages sent on other channels. For example, the provide synchronous message passing between two threads.

È Ñ

Suppose thread ½ wants to send the message syn-

channel ÓÙÐ sends two (empty) messages on any channel

it is given as an argument: chronously on the channel to thread ½ , after which it con-

È É Ñ ½

tinues as ¾ . Thread blocks waiting for the message

ÐØ ÓÙÐ´µ £ ´µ ´µ Ò

É ´Ñµ

and then continues as thread ¾ . In traditional message-

´µ £ È Ò ÓÙÐ´ µ ÐØ passing notation, this situation might be expressed by the fol- Ordinary handlers remain permanently in the program en- lowing program:

vironment once declared, and are able to react to any number

Ó Ò ´È × Ò ´ÑµÈ µ´É Ö Ú ´ÜµÉ ´Üµµ Ó Ò

½ ¾ ½ ¾ ÈÊ

of messages sent on the channels they deﬁne. also sup- Ë

linear channels

Ê ports , on which exactly one message must be Ê ¾

Writing ½ for sequential composition of (sequential)

´ £

Ê sent. The symbol is used in place of to indicate that a Ê ¾ processes ½ and , this example can be written using

message handler is linear. For example, the following pro- ÈÊ

’s join patterns: Ë

gram declares a linear channel that must be used exactly

ÐØ ×Ò ´Üµ ÖÚ ´µ £ È É ´Üµ

¾ ¾

once along each execution path, as shown in this example:

Ò È ×Ò ´Ñµ É ÖÚ ´µ

½ ½

ÐØ ´Üµ ´ Ð Ü Ò

2Join patterns could be implemented using mutexes or semaphores.

ØÒ ´Øµ Ð× ´µ

ÈÊ

ÐØ ´µ ´µ ´ Ì Ò

¼ ½

security loop guards [38, 36]. However, does rule out

ÐØ ´µ ´µ ´ Ë ´µ Ò

¿ ¼

¾ programs that other systems consider secure [17, 38, 19, 36],

È ´ É ´ Ê ´µ Ê ´µµ É ´µµ

½ ½ ¾ ¿ ¾ ¾ ½ because those programs allow reﬁnement attacks. It is our

belief that these different approaches embody a tradeoff in Ê

6 /o/o/o/o½/o/o/o/o/ ¡ mm ¡ C secure systems design. In cases where absolute security is

É C ½ m

6 /o/o/Qm CC ¡ mm ¡ QQ C mandatory, the more restrictive languages may be required.

m Q Ê !

¾ Ì

/oÈ /o/m ( /o/o/Q 6 /o/o/

¡ ¡ ¡ ¡ ¡ ¡ CC QQQ mmm

CC 6( /oË /o/m However, there are many circumstances in which external ¡ C mm ¡ ! É m

/o/o/o/o¾/o/o/o/o/m timing and termination channels are acceptable risks. ¡ ¡ Linearity is an important feature because it improves rea- Figure 1. Nonnested synchronization soning about implicit ﬂows: information ﬂows arising from program control structure [8]. In the producer-consumer ex-

ample of Figure 1, knowing that the code at Ì is executed

ÈÊ also allows join patterns for linear channels. For È

Ë gives no more information than knowing that was exe-

example, the program below declares a handler for two linear cuted. Linearity makes it possible to determine this despite

½ channels ¼ and : the complex control structure. Prior secure concurrent lan-

guages are either unable to express this program or reject

ÐØ ´µ ´Üµ ´ È Ò É ½ ¼ it as insecure, which is unfortunate because the producer-

consumer idiom is useful.

½ Channels ¼ and must be used exactly once in each pos-

sible execution path of the process É.

ÈÊ

Join patterns in permit complex synchronization Ë 4 : A secure concurrent calculus

behavior. For instance, the program shown in Figure 1 has Ë ÈÊ

This section introduces the formal semantics for ,in- the synchronization structure pictured there, where wavy ar- Ë rows represent computation and straight arrows represent cluding its syntax, operational semantics, and type system. process forking or synchronizing message sends. The exam-

ple is a single-message producer-consumer pair. Note that 4.1 Syntax and operational semantics

ÈÊ ¼

this program uses channel inside the body of the handler Figure 2 shows the syntax for programs. Base val-

ÈÊ

¾ ¿

deﬁning channels and . ues in are channel names , memory locations ,or

The typical synchronization mechanisms for shared- booleans Ø and . The metavariable ranges over channels

memory programming are locks, such as mutexes and and variables that have channel or linear channel type. A ÈÊ

semaphores. Like other process calculi [26, 13], does process thread process

Ë (“ ”and“ ” are used interchangeably) ÐØ

not directly support these mechanisms. Though their addi- È consists of a sequence of -declarations and primitive

tion would be straightforward, locks do not interact with in- operations followed by either the terminal process ¼,an

È È ¾ formation ﬂow analysis as congenially as message-passing expression, or ½ . Message sends and handlers are does. Locks are primarily used to obtain atomicity, which as described in the previous section. Nonlinear join patterns

is useful for writing correct programs, but it provides little may bind linear variables Ý (although they are not required help in reasoning about timing ﬂows. For example, given a to), but linear join patterns never bind linear variables. This

critical section controlled by a mutex, the order of arrival of restriction prevents problems in sequencing linear sends. ÈÊ

two threads can leak as much information as if there were no It is helpful to deﬁne a sequential subset of :pro-

È ´Ý µ mutex. Locks can be used as limited message-passing mech- cesses not containing the symbol. If is a sequential

anisms, and it is plausible that a precise information ﬂow process that contains one free linear channel variable Ý ,the

É ÐØ Ý ´µ ´ É Ò È ´Ý µ analysis could be constructed for those uses. process È is sugar for . Figure 2 also describes a program’s dynamic state. A

3.3 Expressiveness memory Å contains channel handler deﬁnitions in addition

Security-typed languages rule out apparently insecure pro- to ordinary mappings between locations and their values; its

Â Ê È domain is generalized to include the join patterns deﬁnes.

grams and thus may reduce expressiveness. While has

Å µ Ä

a relatively rich collection of features in comparison with the The function ÓÑ´ is the set of locations and join pat-

Å Ä ¾ ÓÑ´Å µ

previous work, it is difﬁcult to directly compare expressive- terns Â that appear in .If then we write

´Äµ Ú Ä Ú ¾ Å

ness because of the differing deﬁnitions of security. Å for the value such that . Similarly,

Â ¾ ÓÑ´Å µ Å ´Â µ È ÈÊ if , we write for the (open) process

Channels in are quite expressive. A channel is an

Â £ È ¾ Å Ë extension to a continuation: both accept a value and cause such that .Asynchronization environment

ÈÊ stores the linear handlers that have been declared by the pro-

some computation to occur, possibly using the value. Ë is in fact an extension of a secure CPS language introduced gram, using similar notation. Program-counter labels (Ô)

in the authors’ earlier work [49]. Thus adding concurrency are used to track implicit information ﬂows [49, 30]. The

Ô È È Ô causes no loss of expressiveness, unlike in various previ- syntax associates a top-level process with a ous secure concurrent languages that have ruled out high- label. A collection of such processes running concurrently is

¾ Î

Ü Variable names

Å ´Ä µÚ

Ô Ú · Ú Ø Ô Å Ô Ä · Ú Ø Ô

Channel value Å Ä

Reference value

¼ ¼

Ø Ô Ô Ò ¨ Ò · ´Ò¨Ò µ

Boolean values Å

Ú Ü

Å Ô Ú

Variables prim ·

Secure values

Å Ë ´Æ Ô ÐØ Ü Ò µ

prim

Å Ë ´Æ Ô ÚÜ µ

ÐÚ Linear values

Å Ë ´Æ Ô ÐØ Ü Ö Ú Ò È µ

ÔÖ Ñ Values

Å Ä Ú Ë´Æ Ô È Ä Ü µ

Ú ¨ Ú

Boolean operations

Ä ¾ ÓÑ´Å µµ

where ´

Dereference

Å Ë ´Æ Ô ×Ø Ä Ú Ò È µ

Ü Ý

Variables or channels

Å Ä Ú Ø Ø ÔË´Æ Ô È µ

Ä ¾ ÓÑ´Å µµ

where ´

´ÜÝµ

Â Nonlinear channel

´Üµ

Linear channel

Å Ë ´Æ Ô Ø Ø Ò È Ð× È µ

½ ¾

Â Â

Join pattern

Å Ë ´Æ Ô Ø È µ

ÐØ Ü ÔÖ Ñ Ò È

È Primitive operation

Å Ë ´Æ Ô Ø Ò È Ð× È µ

½ ¾

ÐØ Ü Ö Ú Ò È

Reference creation

Å Ë ´Æ Ô Ø È µ

×Ø Ú Ú Ò È

Assignment

ÐØ Â £ È Ò È

Handler deﬁnition

Å Ë ´Æ Ô ÐØ ´Ü µ ´Ü µ £ È Ò È µ

½ ½ Ò Ò ½ ¾

ÐØ Â ´ È Ò È

Linear handler deﬁnition

Å Ô ´Ü µ ´Ü µ £ È ´ µ Ë

½ ½ Ò Ò ½ Ô

ÓÔØ

Ú ´Ú ÐÚ µ

Message send

´Æ Ô È ´ µ µ

¾ Ô

ÐÚ ´Úµ

Linear message send

where the are fresh

Ú Ø Ò È Ð× È

Conditional

´È È µ

Parallel processes

Å Ë ´Æ Ô ÐØ ´Ü µ ´Ü µ ´ È Ò È µ

½ ½ Ò Ò ½ ¾ ¼

Inert process

Å ËÔ ´Ü µ ´Ü µ ´ È

½ ½ Ò Ò ½

´Æ Ô È µ

where the are fresh

Å Ä Ú Ä Ú

Å Memory location storing

Å Ô Â £ È

Message handler

ÓÔØ

µ ´Ü Ý µ £ È Ë Å Ô ´Ü Ý

Ò Ò ½ ½

ÓÔØ

´Æ Ô ´Ú ÐÚ µµ

ÓÔØ

Å Ô ´Ü Ý µ ´Ü Ý µ £ È Ë

Ò ½ ½ Ò

Ë Ô Â ´ È

Ë Linear handler

ÓÔØ

´Æ È Ú Ø Ô Ü ÐÚ Ý µ

Ô Ø Û Ö

¡ Æ Ô È

Æ Process pool

Å ËÔ ´Ü µ ´Ü µ ´ È ´Æ Ô ´Ú µµ

½ ½ Ò Ò

Å Ë ´Æ Ô È Ú Ø Ô Ü µ

Å Ë Æ

Ñ Machine conﬁguration

Å Ë ´Æ Ô È Éµ

Ú Ø Ú

´Ø µ

Å Ë ´Æ Ô È Ô Éµ

È È ´ ¾ ½Ò µ È

½ Ò

ÈÊ

Figure 3. operational semantics

Figure 2. Process syntax & notation Ë

called a process pool.Amachine conﬁguration Ñ is a triple

¾ Ä

Ô Security labels

Å Ë Æ Å Ë ,where is a memory, is a synchronization

environment, and Æ is a process pool.

× Ø

Security types ÈÊ

Figure 3 contains the operational semantics for , Ë

instrumented to track information ﬂow within executing

ÓÓÐ Ø Booleans

programs—that this instrumentation is correct is the purpose ÓÔØ

Ô´× µ

Channel types

× Ö

of the security proof. The rules deﬁne a transition relation Reference types

Ñ Ñ ¾

½ between machine conﬁgurations, though space

´×µ limitations preclude full explanation of the semantics. Eval- Linear channel types

uation of primitive operations is described by a large-step

¡ Ü ×

Type contexts

Ô · Ú evaluation relation Å prim .

The evaluation rule for a process about to do a memory

À Empty memory type

Ô ×Ø Ä Ú Ò È

update updates the contents of

À Ä ×

Location type Ú

memory location Ä to contain a security value whose label

À × Channel deﬁnition type

is bounded below by , the security label of the reference

itself (needed to prevent information leaks through aliasing)

¡ Ã Ý Ã Linear type contexts

and Ô (needed to prevent implicit information ﬂows).

¡ Ì The two rules for evaluating conditional expressions show Ì Synchronization state types

how the program counter label approximates the implicit in-

Ð Ð´Ø µ

formation ﬂows that arise due to program control behavior.

Ô Ø ØÒ È Ð× È

½ ¾

The process evolves to the

Ô Ø È process ½ , where the new program counter label Figure 4. Type syntax is the join of the old one and the label of the value that regu- lates the conditional—any assignment operations that occur

composition with structural equivalence:

È Ô Ø

in ½ will propagate the label and so track the implicit

¼ ¼ ¼

information introduced by the branch. ¼

Ñ Ñ Ñ Ñ Ñ Ñ Î Ñ ´µ Ñ

¾ ½ ½ ¾

¾ ½ ¾

Note that the rules for evaluating handler deﬁnitions in- ½ Ê stall their handlers in the appropriate environment, with the È

4.2 type system

channels renamed to prevent collisions; linear handlers also Ë

ÈÊ

Ô The language has a nonstandard type system that en- record the at the point of their deﬁnition. Correspond- Ë

ingly, the rules for sending messages look up the channel in forces the security condition. Figure 4 shows the types for ÈÊ

programs. They are divided into security types and lin-

the appropriate environment and start a thread to execute the Ë Ø

body. The rule for the new Ô differs between linear and ear types. Base types, , consist of booleans, channel types,

Ø Ô nonlinear messages; in the linear case the of the sending and references; security types are pairs consisting of a base

context(s) is discarded and the Ô existing at the evaluation type and a security label annotation.

ÓÔØ

Ô´ × µ

of the handler is used instead—possibly lowering Ô. Linear- The channel type has any number of nonlin-

Ô ity ensures that this is safe [49]: once the handler has been ear arguments and at most one linear argument. The reached, it must also be invoked (unless that thread of con- component of a channel type is a lower bound on the secu- trol does not terminate). Therefore, the future computation rity level of memory locations that might be written to if a

learns nothing from its invocation. message is sent on this channel.

×µ The operational semantics in the ﬁgure are too rigid: they The linear types are channels ´ that accept nonlinear require the right-most processes to take part in the computa- arguments. A linear message does not itself reveal informa-

tional step. Because thread scheduling should ignore the syn- tion about the sending context (although its contents might),

Ô tactic ordering of process pools and processes running con- so linear channel types do not need a component.

currently, we introduce structural equivalences on processes The security lattice is lifted to a subtyping relation on ÈÊ

types, in the usual manner [45, 49]. In particular, non-

and process pools, allowing arbitrary reordering of items Ë

Ô ¼

separated by , and discarding of halted processes ( ). These linear channel types are contravariant in both their -label

Æ È È

Æ and their argument types; reference types are invariant.

¾ ½ ¾ structural equivalences ( ½ , ) are the least

symmetric, transitive congruences allowing these transfor- A type context is a ﬁnite map from nonlinear vari-

Å Ë Æ

ables to their types. Linear type contexts are ﬁnite maps

½ ½

mations. Finally, two machine conﬁgurations ½

Å Ë Æ «

from linear variables to linear types. A memory type,

¾ ¾

and ¾ are structurally equivalent if they are -

Æ (for heap), is a mapping from locations and channels to their ¾ equivalent and ½ .

The syntax-independent operational semantics is given by types. A synchronization state type Ì similarly maps linear the transition relation Î deﬁned from the relation by channels to their linear types. The typing judgments are deﬁned by the rules in Fig- ure 5. These judgments make use of auxiliary judgments

8 Proceedings of the 16th IEEE Computer Security Foundations Workshop (CSFW’03) 1063-6900/03 $17.00 © 2003 IEEE that ensure values, linear values, and primitive operations are well-typed (Figure 6). For space reasons we have omitted the straightforward judgments for deciding that memories, synchronization environments, and process pools are well- formed, as well as the subtyping and subsumption rules. The type system guarantees the following properties:

¯ Explicit and implicit insecure information ﬂows are

Ô ÔÖ Ñ ×

ruled out, if the program is also race-free. À

À Ü × Ì Ã Ô È

Ì Ã Ô ÐØ Ü ÔÖ Ñ Ò È PRIM À ¯ Channel names introduced by a linear handler are used

exactly once in each possible future execution path.

À Ú × Ô Ú Ð Ð´×µ

À Ü × Ö Ì Ã Ô È

Ì Ã Ô È

Typing judgments have the form À ,

Ì Ã Ô ÐØ Ü Ö Ú Ò È

which asserts that process is well-typed in the context REF À

Ì Ã Ô

deﬁned by À , , , , and a program-counter label .

À Ú × Ö À Ì Ã Ô È

Nonlinear contexts permit weakening and contraction,

À Ú × Ô Ø Ú Ð Ð´×µ

whereas linear contexts Ã do not; thus, a process typed as-

Ì Ã Ô ×Ø Ú Ú Ò È suming a set of linear message handlers must use all of them. ASSN À

The type system uses the Ô label to bound what can be

À Ô Ú ÓÓÐ È

learned by seeing that the program execution has reached .

À Ì Ã Ô Ø È ´ ¾½ ¾µ

The component of the judgment is thus a lower bound

À Ì Ã Ô Ú Ø Ò È Ð× È ¾ on the label of memory locations that may be written by . IF ½

The rule that increases Ô is IF, because branching transfers

¡ ¡ Ô ¼ information to the program counter. ZERO À

Most of the typing rules are similar in spirit to those in

À Ì Ã Ô È ´ ¾½ ¾µ

recent security-typed languages [17, 49, 30], though there

À Ì Ì Ã Ã Ô È È

¾ ½ ¾ ½ ¾

are a few rules of special interest. PAR ½

È È ¾

Concurrent processes ½ are checked using the

Â Ã

Ô Ö × Ö ×

program-counter label of the parent process, as shown in rule

À ¡Ã Ô È

Ö× Ö × ½

PAR of Figure 5. The two processes have access to the same

À Ì Ã Ô È ¾

nonlinear resources, but the linear resources must be parti-

À Ì Ã Ô ÐØ Â £ È Ò È ¾ tioned between them. LET ½

The typing rules LET and LETLIN make use of aux-

Â Ã Ö ×

iliary operations that extract variable binding information

À Ì Ã Ô È

Ö × ½ ½ ½

from handler deﬁnitions. A join pattern Â yields a collec-

À Ì Ã Ã Ô È

¾ ¾ ¾

tion of channels it deﬁnes and a set of variables bound in

À Ì Ì Ã Ã Ô ÐØ Â ´ È Ò È

¾ ½ ¾ ½ ¾

LETLIN ½

the body of the handler deﬁnition Ö× . For nonlinear join ÓÔØ

patterns, the linear variables form a synchronization context ¼

À Ú Ô ´× µ

Ã Â Ã

Ö ×

. The operation Ô ,deﬁnedinFig-

À Ô Ú ×

ÓÔØ

ure 7 collects these channel names and variables for nonlin- ÓÔØ

Ì Ã ÐÚ

ear join patterns and assigns them types. A similar operation ¼

Ô Ø Ú Ô

Â Ã Ö ×

deﬁned for linear join patterns extracts ÓÔØ

Ì Ã Ô Ú´Ú ÐÚ µ SEND À

the synchronization point Ã and the context for the handler

body, Ö × .

Ì Ã ÐÚ ´×µ

Rule LET checks the body of the handler under the as-

À Ô Ú ×

sumption that the arguments bound by the join pattern have

Ì Ã Ô ÐÚ´Úµ LINSEND À the appropriate types. Nonlinear handlers cannot capture free linear values or channels, because that would poten-

tially violate their linearity. Consequently, the only linear Figure 5. Process typing È

resources available inside the body ½ are those explicitly Ã

passed to the handler: Ö× . Note that the channels deﬁned

by the nonlinear handler ( ) are available inside the handler È

body, which allows recursion. The process ¾ has access

to the newly deﬁned channels (in ) and to the previously

on a linear channel. Note that the contents of the messages

¡ Ý Ý À Ü ´Üµ

are labeled with the Ô label, because the linear message

might contain information about the program counter.

¡ À Ø ÓÓÐ

Ì Ã ÐÚ

4.3 Race prevention and alias analysis

½ ¾ ½

À ÓÓÐ

Ì Ã ÐÚ

¾ As discussed above, two concurrently running threads might

À Ä À ´Ä µ Ø

leak conﬁdential information if they have write–write or

× × À Ú ×

¾ ½

½ read–write races. Rather than further complicating the type

À Ú ×

À À ´µ Ø ¾ system with race-condition analysis, we assume that a sep-

arate program analysis rejects programs that contain such

Ú × Ô Ú Ð Ð´×µ À races. This strategy modularizes the proof of security: Any

program analysis that soundly guarantees race freedom can

À Ô Ú ×

be used in conjunction with this type system.

À Ú ÓÓÐ À Ú ÓÓÐ Ô Ú

The remainder of this section formalizes our race freedom

Ô Ú ¨ Ú ÓÓÐ

À condition and sketches some ways that existing technology

can be used to determine whether a given program satisﬁes

À Ú × Ö Ô Ú Ð Ð´× Ø µ

the condition.

Ô Ú × Ø À Intuitively, the deﬁnition of race freedom requires that steps performed by parallel threads can be interleaved in any

order. Formally, a conﬁguration Ñ is race-free whenever

ÈÊ

¼ ¼ ¼

Figure 6. value and operation types £

Ñ Î Ñ Ñ Î Ñ Ñ Î Ñ Ñ Ñ

¾ ½ ¾

and ½ and and

¼¼ ¼¼

Ñ Ñ Î Ñ

imply that there exists an such that ½ and

¼¼

Ñ Î Ñ

¾ . An open term is race-free whenever its closed

´ Üµ Ô´ ×µ Ü × Ô

instances are race-free.

´ Ü Ýµ Ô´ × µ Ü × Ý

Ô This is a strong notion of race freedom (it implies con-

ﬂuence), though certainly sufﬁcient to rule out timing leaks

Â Ã

½ Ô Ö ×½ ½ ½

that may occur between threads. It is possible to weaken the

Â Ã

¾ Ô Ö ×¾ ¾ ¾

deﬁnition of race freedom to consider harmful only nonde-

Â Â Ã Ã

½ ¾ Ô Ö×½ Ö×¾ ½ ¾

½ ¾ terminism apparent from the memory, but even with a weakened deﬁnition of race freedom, nondeterminism on nonlin-

ear channels can cause races.

´ Üµ ´ ×µ Ü × There are a number of ways to establish race freedom.

One approach is to use an alias analysis to soundly approx-

Â Ã Â Ã

½ ½ Ö×½ ¾ ¾ Ö ×¾

imate the set of locations and channels written to (or sent

Â Â Ã Ã

½ ¾ ½ ¾ Ö ×½ Ö×¾

ÛÖØ´È µ messages) by a thread È . Call this set .Byde-

termining which locations are potentially read by È (a set

Figure 7. Join pattern bindings

´È µ Ö ), an analysis can prevent races by requiring the fol-

lowing (and its symmetric counterpart) for any subprograms

È È ¾ ½ and that might execute concurrently: available resources. Rule LETLIN operates similarly but ex-

ternal linear channels may be used in the handler body.3

ÛÖØ´È µ ´Ö´È µ ÛÖØ´È µµ

¾ ¾ The rule for type-checking sends on nonlinear channels ½ requires that the channel type and the types of the values An alias analysis constructs ﬁnite models of the dynamic passed in the message agree. Also, the program counter at behavior of a program in order to approximate which refer- the point of the send must be protected by the label of the ences are instantiated with which memory locations at run message handler, which rules out implicit information ﬂows. time. The more closely the abstract model agrees with the Sending a message on a linear channel does not impose true behavior of the system, the more accurate aliasing in-

any constraints on the Ô label at the point of the send, be- formation can be. Formulating such an alias analysis is or- cause there is no information revealed by the act of sending thogonal to this work; instead, we have simply stated the race-freedom property the analysis must enforce. 3Unlike the related linear-continuation type system [49], the type system presented in Figure 5 does not explicitly enforce any ordering constraints on One trivially sound analysis is to assume that any process the use of linear channels, relying instead on race freedom. Race freedom might read or write any reference. Such a rough approxima- implies that there is a causal relationship between the linear synchronization tion to the actual aliasing forces the program to be sequen- handlers such that any two handlers that interfere are totally ordered. Inter- tial. A second possibility is to ensure that references and fering linear handlers are used sequentially, so updates to memory locations mentioned in the handlers are deterministic. nonlinear channels are used sequentially. Simple syntactic constraints can enforce this property [31]. Sequentiality can

rather complex.

À Ú Ú Ø ¸

Another possibility is to track aliasing directly in the type ½

À Ú Ø ´ Ú µ Ú Ú µ

½ ¾ system [40, 46], which would potentially permit very ﬁne-

grained control of concurrency. More generally, pointer ¯ For linear values:

´ µ

or shape analysis can be used to approximate Ö and

Ì ¸ Ì ´ µ

½ ¾ ½ ¾

ÈÊ

´ µ

ÛÖØ [21, 9, 10, 33]. Because ’s sequential core is Ë

essentially an imperative language with ÓØÓ, we expect that 5.3 Process simulation these existing alias analyses can be adapted to this setting.

Generalizing -equivalence to processes is more involved because there can be both high-security and low-security 5 Security condition computations running simultaneously, making it harder to

We now present more formally the security condition that relate corresponding parts of subprograms. Bisimulation- ÈÊ

the language enforces and give an outline of the proof based proof techniques for noninterference are no longer ap-

techniques used. propriate. Rather than giving a deﬁnition of for traces

ÈÊ

Well-typed programs satisfy the determinism-based directly, we instead give a simulation relation . Two pro- Ë

security condition described informally in Sections 2.3 and grams are then -equivalent if they can both be simulated by 2.4. The proof strategy is to show that regardless of the high- the same program.

security inputs to a program, its low-security memory access The simulation relation is induced by the typing structure

Ñ º Ñ

behavior can be simulated by a single, deterministic program of a source machine conﬁguration. Intuitively, if ¼

that differs only in its high-security parts. The existence of then conﬁguration Ñ can simulate the low-security behavior

a common simulation implies that low-security behavior re- of Ñ while ignoring both the timing and termination behav-

veals nothing about the inputs. ior of the high-security computation in Ñ.

The remainder of this section sketches the proof that the

º type system in conjunction with a race-freedom analysis Definition 5.2 ( -simulation) Let be the relation (mutu- implies the security condition. A complete proof is avail- ally) inductively defined as shown in Figures 8, 9, 10, 11 and able [48]. in the rules below. For configurations: SIM-CONFIG

5.1 Subject reduction

À Å º Å

½ ¾

À Ì Ì Ë º Ë Ì

¾ ½ ¾ ¾

Subject reduction is a crucial ﬁrst step of the security ½

À ¡ Ì ¡Æ º Æ

½ ¾

proof because it establishes that evaluation preserves well- ¾

formedness.

À Ì Ì Å Ë Æ º Å Ë Æ

½ ¾ ½ ½ ½ ¾ ¾ ¾

Lemma 5.1 (Subject reduction) Suppose that

For processes with Ô : SIM-HIGH-PROC

¼ ¼ ¼

Ì Å Ë Æ Å Ë Æ Å ËÆ

À and

Ô Ú Ì ´ µ´× µ À Ú ×

¼ ¼ ¼ ¼ ¼ ¼ ¼

Ì À Ì Å ËÆ

Then there exist À and such that .

À Ì ¡ Ô È º ´Ú µ

¼ ¼

À Ì Ì

Furthermore, À extends , and and agree on the

Ú º channels in their intersection. Ô

For processes that are well-typed with ,the relationship acts homomorphically on the typing rule of the

Proof: The proof is by cases on the evaluation step used.

Ú × term, replacing the judgment À with the equiva-

A number of additional lemmas are needed:

À Ú Ú ×

¾ lence rule ½ (and similarly for primitive

¯ Substitution: the usual lemmas for type preservation operations). For example, the simulation for conditionals is when substituting for linear and nonlinear variables; derived from the typing rule IF:

¯ Weakening: preservation of typing judgments when

Ô Ú

program counter labels are lowered or heap types and

À Ô Ú º Ú ÓÓÐ

½ ¾

synchronization environments are extended. ¾

À Ì ¡ Ô Ø È º È ¾½ ¾

½ ¾

À Ì ¡ Ô Ú Ø Ò È Ð× È º

½ ½½ ½¾

Ú Ø Ò È Ð× È

5.2 Observational equivalence

¾ ¾½ ¾¾

The -equivalence relation indicates when two values look º the same to a low-level observer. The most important part of the relation is

SIM-HIGH-PROC. This rule says that any process that is

Deﬁnition 5.1 ( -equivalence) Let -equivalence (written well typed with a label not protected by can be sim-

) be the family of symmetric binary relations inductively ulated by the process that just sends a response on each of deﬁned as follows. the linear channels. Intuitively, this simulation bypasses all

of the potential high-security computation performed in È

À Ú Ú × Ô Ú Ð Ð´×µ

½ ¾

and simply returns via the linear-channel invocations. Im-

À Ô Ú º Ú ×

½ ¾

º È È SIM-VAL

portantly, for high-security process the simulation

¼ È

È always terminates, even if does not; the simulation ig-

À Ú Ú ÓÓÐ

½½ ½¾

nores the termination behavior of È .

À Ú Ú ÓÓÐ Ô Ú

¾½ ¾¾

Observe that any value returned from a high-security con-

À Ô Ú ¨ Ú º Ú ¨ Ú ÓÓÐ

½½ ½¾ ¾½ ¾¾ text via linear channels must itself be high-security, because SIM-BINOP

its label must protect that context’s program-counter label.

À Ú Ú × Ö Ô Ú Ð Ð´× Ø µ

½ ¾

Therefore, it does not matter what value is returned in the

À Ô Ú º Ú × Ø

½ ¾ SIM-DEREF -simulation because that value is not observable anyway.

Also note that if there are no linear channels in the con-

È º ¼ text, the rule SIM-HIGH-PROC says that —the high- Figure 8. Primitive operation simulation

security process È has no way of affecting low-security

À Å

memory locations, so from the low-security view, È may as

Ä ¾ ÓÑ´Å µÐ Ð´À ´Äµµ Ú

well not exist.

¾ ÓÑ´Å µÐ Ð´À ´µµ Ú º

In this setting the relation is more fundamental and

À Å º ¡

IM MPTY

S -E easier to work with than , because is not transitive and

hence not an equivalence relation. Two machine conﬁgura-

À Å º Å À Ú Ú À ´Äµ

½ ¾ ½ ¾

tions are -equivalent if they are both simulated by the same

À Å Ä Ú º Å Ä Ú

½ ½ ¾ ¾

conﬁguration: SIM-LOC

À Å º Å

½ ¾

Deﬁnition 5.3 ( -equivalence for conﬁgurations)

ÓÔØ ÓÔØ

Â À ´ µ Ü × Ý

Ñ Ñ ¾

Conﬁgurations ½ and are -equivalent, written

ÓÔØ

µ À ´ µÔ´×

À Ì Ñ Ñ

½ ¾ ÓÔØ

, if and only if there exists a conﬁgura- ÓÔØ

Ô È º È À Ü × ¡ Ý

½ ¾

Ñ À Ì Ñ º Ñ À Ì Ñ º Ñ

tion such that ½ and .

À Å Â £ È º Å Â £ È

½ ½ ¾ ¾

SIM-J

ÈÊ

To prove that satisﬁes the security condition, we Ë ﬁrst show that the simulation preserves typing and respects Figure 9. Memory simulation

the operational semantics.

À Ì Ë Ì

À Ì Ñ

Ô Â ´ È ¾ ËÔ Ú

Lemma 5.2 (Simulation preserves typing) If

¼ ¼

À Ì Ñ º Ñ À Ì Ñ

and then .

À Ì Ë º ¡Ì

SIM-S-EMPTY

Ì Ñ

Proof: By induction on the derivation of À ;the

À Ì Ë º Ë Ì

½ ¾ ½

Ì ´ µ Ü × inductive hypothesis must be extended to the other judgment Â

´ µ´× µ Ì Ì

IM IGH ROC Ì

¾ forms. The one interesting case is S -H -P ,which

À Ü × Ì ¡ Ô È º È

¾ ½ ¾

holds because each free linear channel mentioned in is

´Ú µ ¾

used exactly once in the simulation .

À Ì Ë Ô Â ´ È º

½ ½

SIM-S-HANDLER

Ë Ô Â ´ È Ì Ì

¾ ½ ¾ Now we establish that the simulation respects the opera- ¾ tional semantics.

Figure 10. Synchronization environment sim-

À Ì Ñ º Ñ

Lemma 5.3 ( -simulation) If ½ and ulation

¼ ¼ ¼ ¼

Ñ Ñ Ñ À Ì º Ñ

½ ¾

then either or there exists , ,

½ ½

¼ ¼ ¼ ¼ ¼ ¼

Ñ Ñ Ñ À Ì Ñ º Ñ ¾

and such that and .

¾ ¾ ½ ¾

À ¡ ¡ ¡ º ¡

SIM-NONE

Proof: This is proved by separately considering low-

À Ì Ã Æ º Æ

½ ½

Ô Ú

security and high-security evaluation steps ( and ¼

À Ì Ã Ô È º È

¾ ¾

Ô , respectively). In either case it is shown that a step

À Ì Ì Ã Ã Æ Ô È º

½ ¾ ½ ¾

½ IM ROC ¼

of can be simulated by zero or one steps performed by S -P ¼

Æ Ô È Ñ

its simulation ¾ . The proofs are by cases on the evaluation

Ñ Î

step taken by ½ . A similar -simulation result follows.

Æ Æ Æ Æ

½ ¾ ¿

À Ì Ã Æ º Æ

¾ ¿

À Ì Ã Æ º Æ

Next, we show that the race-freedom condition im- SIM-EQ

plies deterministic updates. Given a conﬁguration Ñ

Å Ë Æ ´Äµ Å ´Äµ ,wedeﬁneÑ as . Figure 11. Process pool simulation

Lemma 5.4 (Race freedom and determinism) Suppose Proof: By Lemma 5.5 there exists a conﬁguration Ñ that

£ £

Ñ Î Ñ Ñ Î Ñ

¼µ ´¼µ ´¼¼µ ´¼ µ

that both ´¼ and where simulates both conﬁgurations. Suppose, for the sake of con-

×Ø ·½

the last step of each evaluation sequence makes a low- tradiction, that the evaluations disagree on the Ò update Ä

observable change to location Ä, but no prior step does. to the location . We derive a contradiction by induction on

Ñ ´Äµ Ñ ´Äµ Ò ¾

¼µ ´¼ µ Then ´ . , using Lemma 5.4.

Note that in order to establish that a given program is se-

µ Proof: By induction on ´ , applying a collection of related lemmas that use race freedom to reason about equiva- cure, not only must the program be well-typed, but all of its

lence of conﬁgurations after single syntax-independent eval- -simulations must be race-free. An easy lemma shows that

¼ ¼

Ñ º Ñ Ñ Ñ

if and is race-free then is race-free. Con- uation steps. ¾ sequently, it sufﬁces to perform the race-freedom analysis on the original source program—if the original program is To talk about programs that differ only in high-security race-free, all of its simulations are too.

inputs, we use substitutions. A substitution is a ﬁnite map

from variables to values. If is a typing environment and

is a substitution, we write to mean that assigns 6 Related work

each variable a value of the type required by . The notation There has been a long history of information-ﬂow research

´µ

is short-hand for simultaneous capture-avoiding substi- based on trace models of computer systems [14, 23, 16, 25,

¾ tutions. We write ½ if the two substitutions 47] and process algebras [34, 39, 35]. Early programming

satisfy and map each variable to equivalent values given languages work in this area was initiated by Denning [8] and

heap type À . Reynolds [31]. The following lemma says that starting from a configura- A few researchers have investigated noninterference- tion with an open process pool and closing it under equiva- based type systems for concurrent languages and process cal- lent substitutions yields equivalent configurations. culi. Smith and Volpano have assumed a fixed number of threads and a uniform thread scheduler; however, their work Lemma 5.5 (Simulations and high-substitution) accounts for probabilistic thread scheduling and relaxes the Suppose the following hold: constraints due to timing channels [43, 44, 41].

McLean [24] and Roscoe [32] proposed determinism-

À Å Ò À Ì Ì Ë Ì Ò À Ì ¡Æ

¾ ½ ¾

½ based deﬁnitions of noninterference for trace-based and

Ò À

½ labeled-transition systems. Their approach has not been used

Ò Ü ¾ ÓÑ´ µ Ð Ð´ ´Üµµ Ú previously in type systems for programming languages.

Then for any conﬁguration Ñ, Focardi and Gorrieri [12] have implemented a ﬂow-

À Ì Å Ë ´Æ µ º Ñ

½ implies checker for a variant of Milner’s calculus of concurrent sys-

À Ì Å Ë ´Æ µ º Ñ ¾ tems (CCS). Honda et al. have proposed a similar system

for the -calculus in which they can faithfully encode Smith Proof: An easy induction on the typing derivation for pro- and Volpano’s language [19]. Their work relies on a sophis-

cess pool Æ . The inductive cases follow from the construc- ticated type system that distinguishes between linear chan-

º ¾ tion of . nels, afﬁne channels, and nonlinear channels. Both of these approaches use bisimulation to prove possibilistic noninterference properties. A similar approach is taken by Abadi 5.4 Determinism-based security and Gordon to prove the correctness of cryptographic protocols in the Secure Pi Calculus [2], but they do not enforce Given the technical machinery above, we can state the secu- information-ﬂow policies. rity theorem as follows.

Hennessy and Riely consider information-ﬂow properties Theorem 5.1 (Determinism-based security) Let be an in the asynchronous -calculus [18]. Like the deﬁnition used arbitrary label in the security lattice. Suppose that here, their may-testing version of noninterference is timing-

and termination-insensitive, though possibilistic. Their lan-

Ü × ¡ ¡Æ À guage does not support synchronous communication or re-

ﬁnement of the ﬂow analysis via linearity constraints.

À Å Let an initial memory Å be given such that and

Pottier [29] gives an elementary proof of possibilistic

À ¡Å ¡Æ º Ñ

suppose that whenever the simula-

noninterference for a variant of the -calculus, but its type

Ä ¾ ÓÑ´À µ tion Ñ is race-free. Let location be given such

system is restrictive because it does not make a distinction

´À ´Äµµ Ú Ð Ð´×µ Ú that Ð Ð . Further suppose that .

between linear and nonlinear channel usage. Conchon [6]

Ú Ú À ¡Ú ×

¾ Then for any two values ½ and such that the also gives a similar information analysis for the join calcu-

sequence of values stored in memory location Ä during the

lus, with a strong security condition based on bisimulation.

Å ¡Æ Ú Ü

evaluation of ½ is a preﬁx of the sequence of

Ä Å ¡Æ Ú Ü

values stored in by ¾ (or vice-versa).

13 Proceedings of the 16th IEEE Computer Security Foundations Workshop (CSFW’03) 1063-6900/03 $17.00 © 2003 IEEE Sabelfeld and Sands have considered concurrent lan- 7.1 Acknowledgments guages in a probabilistic setting [38], achieving scheduler in- The authors would like to thank Dan Grossman, E Lewis, dependence. They use a novel probabilistic bisimulation ap- Greg Morrisett, Andrei Sabelfeld, Fred Schneider, and proach to specify noninterference properties, and have used Stephanie Weirich for their suggestions about earlier drafts the techniques to prove correct Agat’s program transforma- of this work. The comments of the anonymous reviewers tion for eliminating timing channels [3]. However, this trans- also improved the paper.

formation does not allow high-Ô loops or recursive functions, and it allows leaks through instruction-cache effects. Mantel and Sabelfeld [22] have also considered type systems References for multithreaded secure message-passing languages, includ- [1] M. Abadi, A. Banerjee, N. Heintze, and J. Riecke. A core ing the use of Agat’s transformation to pad timing chan- calculus of dependency. In Proc. 26th ACM Symp. on Prin- nels [36] and thus achieve scheduler independence. ciples of Programming Languages (POPL), pages 147–160,

ÈÊ San Antonio, TX, Jan. 1999. The design of was inspired by concurrent process Ë [2] M. Abadi and A. Gordon. A calculus for cryptographic calculi such as the -calculus [26] and especially the join calculus [13]. protocols: The spi calculus. Information and Computation, 148(1):1–70, Jan. 1999. [3] J. Agat. Transforming out timing leaks. In Proc. 27th ACM 7 Conclusions Symp. on Principles of Programming Languages (POPL), pages 40–53, Boston, MA, Jan. 2000. This paper makes two contributions: first, it presents and [4] A. Banerjee and D. A. Naumann. Secure information flow formalizes in a language setting a definition of information and pointer confinement in a java-like language. In Proc. security based on observational determinism. This definition of the 15th IEEE Computer Security Foundations Workshop, has the advantage over possibilistic security properties that 2002. it is immune to refinement attacks, eliminating covert chan- [5] G. Boudol and I. Castellani. Noninterference for concurrent nels based on the observation of the probabilities of possible programs and thread systems. Merci, Maurice, A mosaic in results. Two insights make the observational determinism honour of Maurice Nivat, 281(1):109–130, June 2002. [6] S. Conchon. Modular information flow analysis for process an effective basis for a security condition: internal and ex- calculi. In I. Cervesato, editor, Proc. Foundations of Com- ternal timing channels are treated differently, and programs puter Security Workshop, Copenhagen, Denmark, 2002. are required to be race-free, eliminating their ability to ob- [7] D. E. Denning. A lattice model of secure information flow. tain information from the internal timing channels. Based Comm. of the ACM, 19(5):236–243, May 1976. on these insights, the attacker is formally modeled as having [8] D. E. Denning and P. J. Denning. Certification of Programs less power to observe differences between program execu- for Secure Information Flow. Comm. of the ACM, 20(7):504– tions, with the result that the security definition avoids some 513, July 1977. of the restrictiveness of alternative noninterference defini- [9] A. Deutsch. Interprocedural may-alias analysis for pointers: tions. Thus, this work allows a tradeoff in expressiveness Beyand k-limiting. In Proc. of the ’94 SIGPLAN Conference on Programming Language Design, pages 230–241, 1994. basedonanestimationofthepoweroftheattacker. [10] M. Emami, R. Ghiya, and L. Hendren. Context-sensitive The second contribution is a demonstration that this new points-to analysis in the presence of function pointers. In definition of security can be enforced by the type system of Proc. of the ’94 SIGPLAN Conference on Programming Lan- a concurrent language with expressive thread communica- guage Design, pages 242–256, June 1994. tion primitives in conjunction with a program analysis used [11] R. J. Feiertag. A technique for proving specifications are mul- to guarantee race freedom. Factoring the security analy- tilevel secure. Technical Report CSL-109, SRI International sis into a type system and an alias analysis simplifies the Computer Science Lab, Menlo Park, California, Jan. 1980. type system and permits more sophisticated analyses to be [12] R. Focardi and R. Gorrieri. The compositional security plugged in to obtain more precise characterizations of in- checker: A tool for the verification of information flow security properties. IEEE Transactions on Software Engineering, formation flow. The language and its type system support 23(9), Sept. 1997. linear message handlers that can synchronize on messages [13] C. Fournet and G. Gonthier. The Reflexive CHAM and the

from multiple threads; this feature enables a less restrictive Join-Calculus. In Proc. ACM Symp. on Principles of Pro- ÈÊ

treatment of implicit ﬂows. The language is not a full-

Ë gramming Languages (POPL), pages 372–385, 1996. featured programming language; nevertheless, it includes the [14] J. A. Goguen and J. Meseguer. Security policies and security key features that research on process calculi have shown to models. In Proc. IEEE Symposium on Security and Privacy,

be important for concurrent programming. Therefore, the pages 11–20. IEEE Computer Society Press, Apr. 1982. Ê È [15] J. A. Goguen and J. Meseguer. Unwinding and inference

security analysis of should extend to other concurrent Ë

ÈÊ control. In Proc. IEEE Symposium on Security and Privacy,

languages that support message passing. In addition, Ë pages 75–86. IEEE Computer Society Press, Apr. 1984. is likely to be useful in designing secure intermediate lan- [16] J. Gray III and P. F. Syverson. A logical approach to multi- guages, just as secure sequential calculi have been [49, 50]. level security of probabilistic systems. In Proceedings of the IEEE Symposium on Security and Privacy, pages 164–176. IEEE Computer Society Press, 1992.

14 Proceedings of the 16th IEEE Computer Security Foundations Workshop (CSFW’03) 1063-6900/03 $17.00 © 2003 IEEE [17] N. Heintze and J. G. Riecke. The SLam calculus: Program- [37] A. Sabelfeld and A. Myers. Language-based information- ming with secrecy and integrity. In Proc. 25th ACM Symp. on flow security. IEEE Journal on Selected Areas in Communi- Principles of Programming Languages (POPL), pages 365– cations, 21(1), Jan. 2003. 377, San Diego, California, Jan. 1998. [38] A. Sabelfeld and D. Sands. Probabilistic noninterference for [18] M. Hennessy and J. Riely. Information flow vs. resource ac- multi-threaded programs. In Proc. of the 13th IEEE Com- cess in the asynchronous pi-calculus. ACM Transactions on puter Security Foundations Workshop, pages 200–214. IEEE Programming Languages and Systems, 24(5), Sept. 2002. Computer Society Press, July 2000. [19] K. Honda and N. Yoshida. A uniform type structure for secure [39] S. Schneider. Security properties and CSP. In Proc. IEEE information flow. In Proc. 29th ACM Symp. on Principles of Symposium on Security and Privacy, 1996. Programming Languages, pages 81–92, Jan. 2002. [40] F. Smith, D. Walker, and G. Morrisett. Alias types. In Proc. of [20] B. W. Lampson. A note on the confinement problem. Comm. the 9th European Symposium on Programming, volume 1782 of the ACM, 16(10):613–615, Oct. 1973. of Lecture Notes in Computer Science, pages 366–381, 2000. [21] W. Landi and B. Ryder. A safe approximation algorithm for [41] G. Smith. A new type system for secure information flow. In interprocedural pointer aliasing. In Proc. of the SIGPLAN ’92 Proc. of the 14th IEEE Computer Security Foundations Work- Conference on Programming Language Design, June 1992. shop, pages 115–125. IEEE Computer Society Press, June [22] H. Mantel and A. Sabelfeld. A unifying approach to the se- 2001. curity of distributed and multi-threaded programs. Journal of [42] T. V. Vleck. Timing channels. poster session, IEEE Computer Security, 2002. To appear. TCSP conference, Oakland CA, May 1990. Available at [23] D. McCullough. Noninterference and the composability of http://www.multicians.org/timing-chn.html. security properties. In Proc. IEEE Symposium on Security [43] D. Volpano and G. Smith. Probabilistic noninterference and Privacy, pages 177–186. IEEE Computer Society Press, in a concurrent language. Journal of Computer Security, May 1988. 7(2,3):231–253, Nov. 1999. [24] J. McLean. Proving noninterference and functional correct- [44] D. Volpano and G. Smith. Verifying secrets and relative se- ness using traces. Journal of Computer Security, 1(1), 1992. crecy. In Proc. 27th ACM Symp. on Principles of Program- [25] J. McLean. A general theory of composition for trace sets ming Languages (POPL), pages 268–276. ACM Press, Jan. closed under selective interleaving functions. In Proc. IEEE 2000. Symposium on Security and Privacy, pages 79–93. IEEE [45] D. Volpano, G. Smith, and C. Irvine. A sound type sys- Computer Society Press, May 1994. tem for secure flow analysis. Journal of Computer Security, [26] R. Milner, J. Parrow, and D. Walker. A calculus of mobile 4(3):167–187, 1996. processes. Information and Computation, 100(1):1–77, 1992. [46] D. Walker and G. Morrisett. Alias types for recursive data [27] A. C. Myers. JFlow: Practical mostly-static information flow structures. In Workshop on Types in Compilation, Sept. 2000. control. In Proc. 26th ACM Symp. on Principles of Program- [47] A. Zakinthinos and E. S. Lee. A general theory of security ming Languages (POPL), pages 228–241, San Antonio, TX, properties and secure composition. In Proc. IEEE Symposium Jan. 1999. on Security and Privacy, Oakland, CA, 1997.

[28] J. Palsberg and P. Ørbæk. Trust in the -calculus. In Proc. [48] S. Zdancewic. Programming Languages for Information Se- 2nd International Symposium on Static Analysis, number curity. PhD thesis, Cornell University, 2002. 983 in Lecture Notes in Computer Science, pages 314–329. [49] S. Zdancewic and A. C. Myers. Secure information ﬂow via Springer, Sept. 1995. linear continuations. Higher Order and Symbolic Computa- [29] F. Pottier. A simple view of type-secure information ﬂow in tion, 15(2–3):209–234, Sept. 2002.

the -calculus. In Proc. of the 15th IEEE Computer Security [50] S. Zdancewic, L. Zheng, N. Nystrom, and A. C. Myers. Se- Foundations Workshop, 2002. cure program partitioning. ACM Transactions on Computer [30] F. Pottier and V. Simonet. Information ﬂow inference for ML. Systems, 20(3):283–328, Aug. 2002. In Proc. 29th ACM Symp. on Principles of Programming Lan- guages, Portland, Oregon, Jan. 2002. [31] J. C. Reynolds. Syntactic control of interference. In Proc. 5th ACM Symp. on Principles of Programming Languages (POPL), pages 39–46, 1978. [32] A. W. Roscoe. CSP and determinism in security modeling. In Proc. IEEE Symposium on Security and Privacy, 1995. [33] R. Rugina and M. Rinard. Pointer analysis for multithreaded programs. In Proc. of the ACM SIGPLAN 1999 Conference on Programming Language Design, pages 77–90, May 1999. [34] P. Ryan. A CSP formulation of non-interference and unwinding. Cipher, pages 19–30, 1991. [35] P. Ryan and S. Schneider. Process algebra and noninterference. In Proc. of the 12th IEEE Computer Security Foundations Workshop. IEEE Computer Society Press, 1999. [36] A. Sabelfeld and H. Mantel. Static conﬁdentiality enforcement for distributed programs. In Proceedings of the 9th Static Analysis Symposium, volume 2477 of Lecture Notes in Computer Science. Springer-Verlag, 2002.