Inference of Usable Declassification Policies

Transcription

1 Inference of Usable Declassification Policies Jeffrey A. Vaughan Stephen Chong Harvard University Abstract We explore the inference of fine-grained human readable declassification policies as a step towards providing security guarantees that are proportional to a programmer s effort: the programmer should receive weak (but sound) security guarantees for little effort, and stronger guarantees for more effort. We present declassification policies that can specify what information is released under what conditions, and define a semantic security condition that specifies what it means for a program to satisfy these policies. The declassification policies are designed to provide precise and intuitive descriptions of potentially dangerous information flow in a program, and also to be amenable to inference. We define and prove sound an analysis that infers declassification policies for programs in a simple imperative language with exceptions. Thus, a program is guaranteed to be secure with respect to the set of declassification policies output by the analysis. We have extended the analysis to an object-sensitive interprocedural analysis for single-threaded Java 1.4 programs, and developed a prototype implementation. 1. Introduction Security-type systems can provide strong information security guarantees [22] but often require enormous programmer effort before these guarantees are achieved. For example, Askarov and Sabelfeld [1] report 150 person-hours to develop a security-typed implementation of a cryptographic protocol, compared to 60 person-hours for a non-security-typed implementation. In this work, we seek to provide information security guarantees that are proportional to a programmer s effort. Specifically, a programmer should be able to receive weak (but sound) security guarantees for little effort, and strong security guarantees for substantial effort. We see this as an improvement over the current state of affairs, in which a programmer must invest considerable time and effort developing a security-typed program before the program type-checks, and the programmer receives any security guarantees. We provide security proportional to programmer effort by inference of fine-grained human-readable declassification policies from source code. We see two key benefits of this approach. Human-readable declassification policies. In this work, we do not seek to specify and enforce the information security requirements of a program; rather, we aim to soundly summarize existing, potentially dangerous, information flows within a program. This change in perspective emphasizes that information security policies should aid programmer understanding of code. Thus, our policies are relatively intuitive, and concisely summarize potentially dangerous information flow in the program. That is, our policies describe what sensitive information may be revealed, or declassified to observers. Inference of security policies. It can be hard to identify what information flows are compatible with a program s desired security properties. During development programmers may not yet clearly understand program structure, and may have difficulty providing security annotations for program variables and function declarations. Inference of security policies during the development process allows a programmer to understand the important information flows in a program, and to then decide if these flows are adequate for the security requirements of the program. If the inferred security policies describe information flows that the programmer or a security audit determine are suitable for the application, no further action needs to be taken. Otherwise, either the program contains insecure information flows, or the analysis is insufficiently precise; regardless, the programmer needs to invest more time and effort into the program s security, by modifying the program, or providing additional information to the analysis. Thus, the programmer can receive weak security guarantees with relatively little effort, and if those guarantees are too weak, can invest additional effort improving the program s security guarantees.

2 An additional benefit is that inference of security policies does not prevent program compilation or execution, and thus does not prevent functional testing or deployment of an application. Our declassification policies describe what information is released under what conditions, and have the form b 1,..., b n e, where b 1,..., b n are booleanvalued expressions, and e is an expression (of any type). Expressions are over constants, sensitive inputs, and non-sensitive inputs to the program. Intuitively, b 1,..., b n e means that an observer of the public outputs of the program may learn the value of expression e if boolean expressions b 1,..., b n are all true. For example, in the program l := h mod 10, an observer may learn the last digit of h (assuming that h is a sensitive input and l is a public output). The policy true hmod10 describes this information flow: the observer may always learn the value of h mod 10. Our analysis soundly tracks implicit information flows [7] information flows through the control structure of a program. For example, our analysis infers that the program satisfies the policies if (h 1 > 0) then l := h 2 else l := 0 true h 1 > 0 and h 1 > 0 h 2. That is, an observer of the final value of variable l may, in all cases, be able to learn whether input h 1 is positive; in addition, if h 1 is positive, then the observer may learn the value of the input h 2. Our inference conservatively tracks information flow in loops and is termination sensitive. The following program copies the initial value in h 1 to variable l, provided that the initial value of h 2 is positive. If h 2 is positive but h 1 is non-positive, the execution will diverge. l := 0; while h 1 > 0 h 2 > 0 do l := l + 1; h 1 := h 1 1 Our analysis determines that the program satisfies the policies true h 1 and true h 2 > 0, that is, observing the final value of variable l may reveal both the initial value of h 1, and the value of the expression h 2 > 0 (which must be true in order for the program to terminate). We have proven our analysis sound for a simple imperative language with exceptions. We have extended the analysis for Java programs, and implemented it as 1 public static void main(string[] args) { 2 List a = new LinkedList(); 3 List b = new LinkedList(); 4 a.add(args[0]); 5 b.add( h 1 args[1]); 6 b.add( h 2 args[2]); 7 System.out.println(a.get(0)); 8 int t = h 3 Integer.parseInt(args[3]); 9 if (t > 0) { 10 for (Iterator i = b.iterator(); i.hasnext(); ) { 11 System.out.println(i.next()); 12 } 13 } 14 } Figure 1. Example Java program an object-sensitive interprocedural analysis. Figure 1 shows a Java program with that takes sensitive input from the command line (indicated by annotations on lines 5,6, and 8), and produces publicly observable output on lines 7 and 11. Our implementation can determine that the output on line 7 reveals nothing about the sensitive inputs, and that the outputs on line 11 satisfy the policies true h 3 > 0, h 3 > 0 h 1, and h 3 > 0 h 2. Thus, an observer of the output can always learn whether h 3 > 0, and if h 3 is positive, then the observer can learn the values of h 1 and h 2. The key contributions of this paper are: Novel declassification policies that are intuitive and amenable to inference. Sound analysis for inference of declassification policies. Implementation of an object-sensitive interprocedural inference analysis for Java. A distinguishing characteristic of our approach is an emphasis on providing security guarantees that are proportional to a programmer s effort: weaker (but sound) guarantees for less effort, stronger guarantees for more effort. We believe that inference of security policies is a promising mechanism to achieve this goal. The rest of the paper is structured as follows. In Section 2 we describe the declassification policies in more detail, and define what it means for a program to satisfy a set of declassification policies. In Section 3 we present a static analysis whose output for a program is 2

3 Arithmetic expr. a ::= n x a 0 + a 1 a 0 a 1 Boolean expr. b ::= true a 0 = a 1 a 0 > a 1 b b 0 b 1 Expressions e ::= a b Variables x Var Exceptions E Ex Commands c ::= x := a c 0 ; c 1 while b do c if b then c 0 else c 1 skip try c 0 catch E c 1 throw E Figure 2. Language Syntax a set of declassification policies that the program satisfies. We describe our implementation of this analysis for Java in more detail in Section 4. Section 5 summarizes related work, and we discuss possible extensions and conclude in Section Policies and security In this section we present our security policies, and define a semantic security condition that holds when the security policies are enforced. Since the policies are defined in terms of program expressions, we first present details of a simple imperative language Language Figure 2 presents the syntax for a simple imperative language with exceptions. Arithmetic expressions and boolean expressions are syntactically distinguished. Program variables are restricted to integer values, and thus the result of only arithmetic expressions may be assigned to variables. Loop guards for while commands and tests for if-then-else commands are boolean expressions. Meta-variable e ranges over both arithmetic and boolean expressions. Command throwe throws exception E, and command try c 0 catch E c 1 will execute c 1 only if c 0 throws exception E. A store σ is a function from variables Var to integers Z. We extend σ homomorphically to a function from expressions (either arithmetic or boolean) to Z B. For example, if σ(foo) = 7, then σ(foo > 0) = true. The semantics of command c define the result of executing c from an initial store σ; the result of execution is a final store σ, and an indication of whether c terminated normally, or by throwing an exception. The semantics of c, written [c] are thus a partial function from Store to Store (Ex {nt}). If [c](σ) = (σ, nt), then execution of command c with initial store σ terminates normally (i.e., without throwing an exception) with final store σ ; if [c](σ) = (σ, E), then execution [skip]σ = (σ, nt) [x := a]σ = (σ[x σ(a)], nt) [c 0 ; c 1 ]σ = let (σ, E ) = [c 0 ]σ in if E = nt then [[c 1 ]σ else (σ, E ) [if b then c 0 else c 1 ]σ = if σ(b) = true then [[c 0 ]σ else [[c 1 ]σ [while b do c]σ = let W = fix λf. λσ. if σ(b) = true then let (σ, E ) = [[c]σ in if E = nt then f(σ, nt) else (σ, E ) else (σ, nt) in W (σ) [throw E ]σ = (σ, E) [try c 0 catch E c 1 ]σ = let (σ, E ) = [c 0 ]σ in if E = E then [[c 1 ]σ else (σ, E ) Figure 3. Language Semantics [c] : Store Store (Ex {nt}) of command c with initial store σ throws (and does not catch) exception E with final store σ. The definition of [c] is presented in Figure 3. We refer to the set Ex {nt} as control channels, and use metavariable K to range over this set. Also, we write σ[x n] to denote the store that maps variable x to n but otherwise is the same as store σ Policies Our security policies restrict what information about a store can be revealed to an attacker. A security policy has the form b 1,..., b n e where b 1,..., b n are boolean expressions, and e is an (arithmetic or boolean) expression. Intuitively, b 1,..., b n e means that if boolean expressions b 1,..., b n all evaluate to true in a store, then the attacker is allowed to learn the evaluation of expression e in that store. We refer to expressions b 1,..., b n as the conditions of the policy, since the release of the evaluation of e is conditional on the satisfaction of these expressions. For example, the policy password = guess secret means that if the boolean expression password=guess evaluates to true, then the attacker is allowed to learn the value of variable secret. 3

4 A policy induces an indistinguishability relation over stores. Two stores σ and σ are indistinguishable according to policy b 1,..., b n e if b 1,..., b n all evaluating to true in both σ and σ implies that σ(e) = σ (e). That is, if the policy conditions are satisfied in both of the stores, then the value of e is the same in both stores, and so an attacker who learns the value of e cannot distinguish the stores. Similarly, a set of policies S induces an indistinguishability relation over stores, given by the intersection of the indistinguishability relations induced by the policies in S. Definition 1 (Indistinguishability according to S). Let S be a set of policies. Stores σ and σ are indistinguishable according to S (written σ S σ ) if for all b 1,..., b n e S, if σ(b 1 b n ) = true and σ (b 1 b n ) = true then σ(e) = σ (e). For any set of policies S, the relation S is an equivalence relation. We write [σ] S for the equivalence class of σ under equivalence relation S Security In this section, we formalize the notion of an attacker that can observe part of the initial and final stores of an execution, and define a program c to be secure with respect to a policy set S if what the attacker is able to learn about the initial store is in accordance with the policies in S. We assume that some subset of variables are low security, and that the attacker can observe the values of only low security variables. We define stores σ and σ to be low equivalent (written σ L σ ) if for every low variable x, σ(x) = σ (x). Intuitively, if σ L σ, then the attacker cannot distinguish stores σ and σ. If variable x is not a low security variable, we refer to x as a high security variable. Suppose that command c executes from initial store σ 0, and terminates with final store σ 1 ; that is, [c](σ 0 ) = (σ 1, K). We assume that the attacker is able to observe the low security variables of both σ 0 and σ 1, that the attacker can observe K (i.e., how the command terminated), and that the attacker knows which command c was executed. By observing the low security variables of the final store and K, the attacker may be able to infer some information about the values of (non-low security) variables in the initial store. Given command c, stores σ 0 and σ 1, and control channel K such that [c](σ 0 ) = (σ 1, K), we define the attacker s knowledge to be the set of initial stores that are low equivalent to σ 0 and could have terminated with control channel K and a final store that is low equivalent to σ 1. That is, the attacker s knowledge is the set of initial stores that are consistent with the attacker s observations of the low security variables of the initial and final stores. Definition 2 (Attacker knowledge). Let c be a command, σ 0 and σ 1 be stores, and K a control channel such that [c](σ 0 ) = (σ 1, K). The attacker s knowledge given c, initial store σ 0, final store σ 1, and control channel K, written k(c, σ 0, σ 1, K), is k(c, σ 0, σ 1, K) = {σ σ L σ 0 [c](σ) = (σ, K) σ L σ 1 }. Command c is secure with respect to policy set S if for all initial stores, the attacker doesn t learn anything about the initial store other than the values of low security variables, and information that policies in S allow to be released. Definition 3 (Security). Command c is secure with respect to policy set S if for all stores σ 0 and σ 1 and all control channels K such that [c](σ 0 ) = (σ 1, K), we have k([c], σ 0, σ 1, K) [σ 0 ] L [σ 0 ] S. For example, given program l := h, the attacker learns the initial value of high security variable h, since the final value of l always contains the initial value of h; other than the initial values of low variables, the attacker learns no additional information. The program is thus secure with respect to policy set {true h}. (In the examples that follow, variables starting with l are low security, and variables starting with h are high security.) A more interesting example is the program if l 1 > 0 then l 2 := h 1 mod 2 else l 2 := h 2 mod 2 where, by observing the final value of variable l 2, the attacker learns the parity of the initial value of either h 1 or h 2, depending on whether variable l 1 is positive. This program is secure with respect to policy set {l 1 > 0 h 1 mod 2, l 1 0 h 2 mod 2} Loops and termination sensitivity Security with respect to policy set S is a terminationsensitive security condition. That is, we assume that the attacker is able to observe the non-termination of commands. More precisely, if [c](σ 0 ) = (σ 1, K) then the attacker s knowledge k(c, σ 0, σ 1, K) contains only stores σ such that execution of c with initial store σ terminates with control channel K. For example, the program while h > 0 do skip is secure with respect to the policy set {true h > 0}, since the program terminates only when h is not positive in the initial store. 4

5 Of course, loops may reveal more information than just whether the loop terminates. The following program, which copies the value of h to the variable l provided h is non-negative, is secure with respect to policy set {true h 0, h 0 h}. That is, the program always reveals (through its termination behavior) whether h 0, and if h is non-negative, the program reveals the initial value of h. l := 0; while h 0 do l := l + 1; h := h Consistent policy sets Consider the following program, which releases h 2 if h 1 is positive. P 4 : if h 1 > 0 then l := h 2 else l := 0 This program is not secure with respect to policy set {h 1 > 0 h 2 }. Suppose the attacker observes in the final state that the value of l is 42. Then the attacker can deduce not only that the initial value of h 2 was 42, but also that the initial value of h 1 is positive! In general, policy b 1,..., b n e allows an attacker to learn not only the initial value of e, but also the fact that b 1,..., b n are all evaluate true in the store. We call a set of policies consistent if the set of policies expresses all such inferences that an attacker may make. That is, if S is a consistent set of policies, and b 1,..., b n e S, then for every non-trivial boolean expression b i there is a policy b 1,..., b m b i S such that for any store σ, if b 1,..., b n all evaluate to true then b 1,..., b m all evaluate to true. (That is, b 1 b n implies b 1 b m.) Definition 4 (Consistency). Set S of policies is consistent if for all b 1,..., b n e S and all i 1..n, either b i = true or there exists b 1,..., b m b i S such that for all stores σ, σ(b 1 b n ) = true implies σ(b 1 b m) = true. Program P 4 above is secure with respect to the consistent policy set {h 1 > 0 h 2, true h 1 > 0} Relation to noninterference Noninterference [10] is a semantic security condition that, in this setting, requires that an attacker learn nothing about the initial values of high security variables: the initial values of high security variables do not interfere with the final values of low security variables. Definition 5 (Noninterference). Command c satisfies noninterference if for all stores σ 0 and σ 1 and control channels K such that [c](σ 0 ) = (σ 1, K), we have k([c], σ 0, σ 1, K) [σ 0 ] L. The policies of this paper specify under what conditions information about the initial values of high security variables may be released to the attacker. Security with respect to policy sets generalizes noninterference, as the following theorem demonstrates. Theorem 1. Command c satisfies noninterference if and only if c is secure with respect to empty policy set. Proof. The result follows immediately since we have [σ 0 ] L = [σ 0 ] L [σ 0 ] S when S =, since [σ 0 ] S is the set of all stores. 3. Sound static analysis This section describes our analysis for inference of declassification policies. We present the analysis, and outline the proof of its soundness Preliminaries In the sequel we denote the set of partial functions from X to Y with X Y. When f X Y we write dom f for the subset of X on which f is defined. The following operators define partial function extension and weak lookup. { y z = x f[ x y ](z) f(z) otherwise { f[x]? f(x) x dom f y y otherwise Notation [ x y ] denotes g[ x y ] where g is the partial function undefined everywhere. Finally, f \ x is the function equal to f on dom f \ {x} and undefined elsewhere. If s is a metavariable ranging over objects defined by a BNF grammar, { s } is the set of all such objects. We write s to refer to a set of such objects, that is, s { s }. Below metavariable pc will range over lists, and pc 2 will denote the append operator. Objects used in the analysis are given semantics in terms of equivalence relations over stores. Such equivalence relations form a join semilattice under the superset ordering. We note that the bottom element of this lattice is the total relation, the top element is the identity relation, and the join operator is set intersection Overview of the analysis The analysis algorithm examines a command in particular context and returns a result summarizing the command s behavior. This is written Γ c :. Store 5

6 Sets of expressions e P({ e }) Abstract expressions a ::= exact(e) infl(e) Program counter, grows to the left pc ::= none a::pc Policy generators g ::= pc > a Generator sets G P({ g }) Store context Γ Var G Writers set W P(Var) Generalized control channels K Ex {nt, div} Output context { K } { Γ } { pc } { W } Figure 4. Objects used in analysis. context Γ maps each variable to a summary of the variable s information content. Here Γ indicates the preconditions assumed when examining command c. Although the declassification policies presented in Section 2 are intuitive, we do not use them to summarize information content during the analysis. In order to accurately track implicit flow, the policy sets produced by the analysis must be consistent (see Definition 4); also, it is useful in the analysis to know when the current value of a variable is exactly equal to an expression over the initial store. We thus use structures that represent only consistent policy sets, and can track the precise value of variables; we describe these structures below. Output context (conservatively) answers three questions: What is the information content of each variable after c has run? What information can the attacker learn by observing how c terminates or fails to terminate? And what variables may be written by c? Output context is a partial map from control channels to triples of the form (Γ, pc, W ). In Section 2, control channels ranged over Ex {nt}, the set of exception names and normal termination. We extend control channels with div, which represents divergence (nontermination), and allows us to track the information associated with nontermination. The triple (Γ, pc, W ) contains a store context Γ, a program counter pc, and a writer set W. (Notations (K).mem, (K).pc, and (K).writerset respectively indicate these quantities.) Before presenting the formal details of the analysis, we first present two examples to provide intuition. First, consider analyzing x := 2 z in store context Γ 0 = [x exact(x), z infl(h 1, h 2 ),...]. Store context Γ 0 means that at this point in the execution of the program, the value of variable x is equal to its initial value, and the value of variable z may be influenced by the initial values of h 1 and h 2. The analysis yields Γ 0 x := 2 z : where = [ nt (Γ 0 [ x infl(h 1, h 2 ) ], none, {x}) ]. Because assignment can only terminate normally, dom = {nt}. Executing the assignment mutates the store, and the store context returned in (nt) reflects that x is now influenced by the same initial variables as z. Because assignment always terminates, program counter (nt).pc is none, indicating that nothing can be learned from observing that normal termination. Finally (nt).writerset = {x} records the command modified the value of variable x. Second, consider analyzing if x > 3 then throw E else skip in Γ 0. Here the analysis returns = [ nt (Γ 0, exact(x > 3)::none, ), E (Γ 0, exact( (x > 3))::none, ) ]. is defined for both nt and E indicating that the command may terminate in two different ways. Because neither branch writes a variable, the writer sets are empty and the store contexts are unchanged. In contrast to the previous example, it is possible to learn something by observing how the program terminates. If exception E is thrown the attacker can learn that the guard evaluated to true this is recorded by (E) mapping to program counter exact(x > 3)::none. Likewise (nt) maps to exact( (x > 3))::none. Thus the program counters summarize the information the attacker may learn by observing the various ways that the command can terminate. The program counters are presented in more detail below Interpreting analysis objects Our analysis tracks the information contained in a variable using policy generators. Store contexts map variables to generator sets G, which are sets of policy generators. A policy generator g has the form pc > a, where pc is a program counter, and a is an expression abstraction. 6

7 [G] {[g ] g G} [none > a] [a] [infl(e)::pc > a] [infl(e)] [pc > a] [exact(e)::pc > a] {(σ 1, σ 2 ) σ 1 (e) = σ 2 (e) = false} {(σ 1, σ 2 ) σ 1 (e) = σ 2 (e) = true and (σ 1, σ 2 ) [pc > a]} [pc ] [pc > infl( )] [infl(e)] {[e] e e} [exact(e)] [infl(e)] [e] {(σ 1, σ 2 ) σ 1 (e) = σ 2 (e)} Figure 5. Equivalence class interpretation of analysis objects. Suppose Γ(x) = {a n ::a n1 ::...a 0 ::none > a}. That is, store context Γ maps variable x to the generator set containing the single generator policy a n ::a n1 ::...a 0 ::none > a. The expression abstraction on the right hand side of the policy generator indicates direct information flows. Expression abstractions contain either (i) precise information, written exact(e), indicating that the current value of x is equal to the valuation of expression e in the initial store; or (ii) a list of expressions that conservatively approximates what expressions over the initial store have influence the current value of x, written infl(e). The left hand side of the policy generator is a program counter, which is a stack of expression abstractions that describe implicit information flows. When infl(e) appears in a program counter, it indicates that the valuation of e in the initial store can influence (via control flow) the current value of x. An occurrence of exact(e) in a program counter also indicates that the valuation of e in the initial store may influence the current value of x; in addition, some information flows to x only occur if the valuation of e in the initial store is equal to true. Policy generators are a compact representation of consistent policy sets. Policy generators and generator sets are readily translated to a set of policies. This translation is given by the function topols( ). topols(g) topols(g) g G topols(none > a) topols(a) topols(infl(e)::g) topols(infl(e)) topols(g) topols(exact(b)::g) {true b} {b p p topols(g)} topols(exact(e)) {true e} topols(infl(e)) {true e e e} We abuse notation and write a::(pc > a) for (a::pc) > a and b (b 1... b n e) for b b 1... b n e. For example the policy generator exact(h > 0)::none > infl(y) represents the consistent policy set { true h > 0, h > 0 y }. That is, the value of h > 0 in the initial store can always be learned, and if H > 0 is true, then the value of y in the initial store may also be learned. By contrast, policy generator infl(h > 0)::none > infl(y) represents the consistent policy set { true h > 0, true y }. Generator sets, policy generators, program counters, and expression abstractions can all be given semantics as equivalence relations over initial stores. This interpretation is written with semantic brackets [ ], and defined in Figure 5. Intuitively, when Γ(x) = G holds at some program point then, for initial stores (σ I 1, σ I 2) [G], running the program from either initial store will yield identical values for x at the program point. The equivalence class interpretation of generator sets agrees with the indistinguishability relation induced by corresponding policy set: [[G] = S where S = topols(g). Generator sets are sometimes less intuitive than the policy sets they represent. For example, generator set {none >exact(x), none >exact(y)} may look contradictory even though it has a well-defined meaning. Generator sets are, however, easier to manipulate in the analysis. We thus use generator sets for the analysis, but use policy sets to define the security condition, and to present the results to users. The analysis uses a syntactic upper bound operator 1 2 to find upper bounds on output contexts. Different definitions for this operator realize different points in the precision-cost curve for analysis. Any definition that respects the semantic ordering will yield a sound analysis Analysis algorithm Figure 6 presents our analysis as an inference system. The rules are syntax directed with one exception: if-singlepath; the rules are turned into an algorithm by applying rule if-singlepath whenever possible, but never twice in succession. 7

8 Γ c : Γ skip : [ nt (Γ, none, ) ] if-skip Γ c : [ K (Γ, pc, W ) ] Γ c : [ K (Γ, none, W ) ] if-singlepath Γ x := e : [ nt (Γ[ x abs Γ e ], none, {x}) ] if-assign Γ c 1 : 1 1 (nt) = (Γ 1, pc 1, W 1 ) Γ 1 c 2 : 2 3 = addwriters (guardpc pc 1 (taint pc 1 2 )) λk.w 1 if-seqlive Γ c 1 ;c 2 : 3 ( 1 \ nt) Γ c 1 : nt / dom if-seqdead Γ c 1 ;c 2 : Γ throw E : [ E (Γ, none, ) ] if-throw Γ c 1 : 1 1 (E) = (Γ 1, pc 1, W 1 ) Γ 1 c 2 : 2 3 = addwriters (guardpc pc 1 (taint pc 1 2 )) λk.w 1 if-trylive Γ try c 1 catch E then c 2 : 3 ( 1 \ E) Γ c 1 : E / dom Γ try c 1 catch E then c 2 : if-trydead a = abs Γ b pc 1 = a::none pc 2 = (negate a)::none (prune a Γ) c 1 : 1 (prune a Γ) c 2 : 2 1 = guardpc pc 1 (taint pc 1 (addwriters 1 2.writerset)) 2 = guardpc pc 2 (taint pc 2 (addwriters 2 1.writerset)) Γ if b then c 1 else c 2 : 1 2 Γ Γ Γ if b then c else skip : ( [nt]? mem ).mem Γ a = abs Γ b Γ while b do c : [ div ( mem, a ::none, Var) ] [ nt ( mem, (negate a )::none, ) ] if-while Figure 6. Analysis rules if-if Rule if-singlepath can apply to any command so long as its output context contains only a single control channel. This rule drops the pc associated with the channel. Intuitively, this rule is sound because when the command can exit in only one way, the attacker cannot learn anything for observing that event. (The single path rule, and our use of output contexts, is inspired by the use of path maps in the Jif security-type system [18, 19].) Executing x := e updates the store and terminates normally. if-assign reflects this by updating input store context Γ to Γ[ x abs Γ e ]. The function abs constructs an abstraction expression using information in Γ and the syntax of expression e. For instance, assume Γ 0 (x) = {none > exact(3)} Γ 0 (y) = {none > exact(h)} Γ 0 (z) = {none > exact(h), none > exact(y)}. Here abs Γ 0 (x + y) = exact(h + 3). By contrast, abs cannot give exact answers when analyzing z: abs Γ 0 z = infl(h, y). We don t show the implementation of abs in this paper. Note that unlike standard information-flow analyses [22] the assignment rule does not address implicit flows. Instead this tainting occurs in rules if-seqlive, if-trylive, if-if, and if-while. Rule if-skip simply shows that skip does not alter the store and always terminates normally. if-seqdead shows that c 1 ;c 2 is equivalent to c 1 when c 1 does not terminate normally. Sequenced commands, c 1 ;c 2, demand more care when c 2 is live. if-seqlive first examines c 1 to find output context 1, then analyzes c 2 under (nt).mem to find 1. Combining 1 and 2 to determine the final output context is interesting. An attacker can learn more from knowing that c 2 ran after c 1 than just by knowing c 2 ran. To reflect this, 2 is updated in three 8

9 taint pc 0 [ k (taint pc 0 Γ W, pc, W ) (k) = (Γ, pc, W ) ] { taint pc (Γ(x)) x W taint pc 0 Γ W λx. Γ(x) otherwise taint pc 0 G {pc g G} guardpc pc 0 (Γ, pc, W ) (Γ, pc W ) guardpc pc 0 [ k guardpc pc 0 (k) k dom ] addwriters 1 f [ k (Γ 1, pc 1, (W 1 W )) (k) = (Γ 1, pc 1, W 1 ) and f[k]? = W ] negate exact(b) exact( b) negate exact(a) exact(a) negate infl(e) infl(e) Figure 7. Functions used in analysis. ways to produce 3. First, we taint variables written in c 2 with 1 (nt).pc = pc 1. This is necessary because observing these variables may let the attacker deduce that c 1 terminated normally. The taint operator has the effect of prepending pc 1 to affected policy generators. Second, observing c 2 s termination behavior may reveal that c 1 terminated normally, so all program counters in 2 are prepended with pc 1. Third, the combined run of c 1 ;c 2 may have written any variables possibly written when c 1 terminate normally. Thus (nt).writerset is unioned into the writer sets in 2. Definitions of the functions used here are given in Figure 7. The final result context is ( 1 \ nt) 3, which combines analysis results for when c 1 executes exceptionally (or diverges) with results for running c 2 after c 1 s normal termination. if-throw, if-trylive, and if-trydead are similar to if-skip, if-seqlive, and if-seqdead. Rule if-if analyzes if e then c 1 else c 2 by examining c 1 and c 2 separately. It is sound to analyze both in the initial memory context Γ, but precision may be improved by refining memory contexts with the function prune. (As with abs we elide the definition, but observe that the identity is a sound choice.) The analysis generates output contexts 1 and 2 for c 1 and c 2. As in if-seqlive these must be modified before returning a final result. Program counters pc 1 and pc 2 capture the information content associated the loop guard evaluating to true and false, respectively. Variables in 1 must be tainted by these program counters if they are written by either c 1 or c 2. This is because observing the value of such a variable may reveal information about the guard. Likewise, all control flow channels are also tainted, since observing a program s termination behavior may reveal information about the loop guard; this step is conservative but precision may be regained by subsequent applications of if-singlepath. We choose to taint variables at program points where control-flow merges from two different potential execution paths, rather than at assignment. This choice makes it easier to compute precise and informative generator sets. A consequence of this design is that the analysis judgment does not take a program counter as an input; this is in contrast to many standard information flow analyses [22]. Finally if-while analyses while b do c by computing a fixed point over if b then c else skip. The attacker may learn something not captured in the fixed point. Whether the program terminates or diverges this leaks information about the state of e. This is captured the two auxiliary contexts, [ div ( mem, a ::none, Var) ] and [ nt ( mem, (negate a )::none, ) ], joined into the result. Note that this rule does not guarantee that searching for will terminate. However search may be cut-off by returning the top output context, and as demonstrated by out implementation, heuristics can balance precision with computational effectiveness Soundness theorem The analysis is sound. Intuitively, if Γ c : holds, then is a conservative approximation of the behavior of c when run in a context summarized by Γ. We make this intuition precise by defining context and behavior. The following definition addresses context. A pair of initial stores σ I 1, σ I 2, and a function f { σ } { σ } are a context summarized by Γ when f evaluated on σ I 1 and σ I 2 respects the Γ s description of information flow. Function f represents the semantics of the program up to this point in the execution. Specifically, for every variable x, if σ I 1 and σ I 2 agree on the valuation of all expressions that might have influenced the current value of x (i.e., (σ I 1, σ I 2) [Γ(x)]), then f(σ I 1) and f(σ I 2) agree on the value of x. Definition 6. (σ I 1, σ I 1, f) : Γ holds if for all variables x, (σ I 1, σ I 2) [Γ(x)] implies f(σ I 1)(x) = f(σ I 2)(x). The following definition address behavior. Intuitively approximates the behavior of command c when the following holds: Running c on stores from 9

10 a context summarized by Γ yields final stores related by [ (K).mem ]. Furthermore, (K).pc describes c s control flow. For brevity and clarity, we introduce new notation to enable uniform quantification over diverging and terminating computations, [c] + [c][σ]? (σ,div), and to select the first component of a store control-channel pair, fst (σ, K) σ. Also, we write f; g for function composition g f. Definition 7. Γ c : holds when for all σ I 1, σ I 2, and f such that (σ I 1, σ I 2, f) : Γ, if (f; [c] + )(σ I 1) = (σ 1, K ) then (i) if (σ I 1, σ I 2) [ (K ).pc ] then (f; [c] + )σ I 2 = (σ 2, K ), and (ii) if (f; [c] + )σ I 2 = (σ 2, K ) then (σ I 1, σ I 2, f; [c] + ; fst) : (K ).mem. We can now formally state the soundness of the analysis. Theorem 2 (Soundness). If Γ c : then Γ c :. Proof Sketch. By induction on the structure of the transfer derivation. For the if-seqlive case, a lemma stating that program counters accurately describe single evaluation traces is needed to use induction hypothesis, Γ 1 c 2 : 2. This lemma requires showing that abs produces conservative approximations of expressions. Full proofs of all theorems are available in the associated technical report, available by request through the program committee chair Security theorem The soundness theorem states that the analysis accurately tracks information flow in the program. However, the analysis has no notion of low security variables. We connect the soundness of the analysis to the security of the program by the following theorem. Let Γ init be the store context that for each variable x, maps x to generator set {none >exact(x)}. Note that for any two stores σ and σ, we have (σ 1, σ 2, λσ. σ) : Γ init. Intuitively, the theorem states that if Γ init c :, then for any control channel on which the program may terminate (K (dom ) (Ex {nt})), the attacker may learn: the termination behavior of the program ( (K).pc); the value of any low security variable when the program terminates ( (K).mem(x)); and, the initial value of any low security variable (Γ init (x)). Theorem 3. Suppose Γ init c :. Let policy set S be the smallest set such that for all control channels K (dom ) (Ex {nt}) and all low security variables x, topols( (K).pc) S, topols( (K).mem(x)) S topols(γ init (x)) S. Then c is secure with respect to policy set S. 4. Implementation for Java and We have extended the static analysis described in Section 3 to an interprocedural analysis for singlethreaded Java 1.4 programs [11], and implemented it as a Polyglot compiler extension [20]. The implementation contains approximately 11,500 non-comment nonblank lines of code. Our analysis is an object-sensitive interprocedural dataflow analysis. It first performs a (nonparameterized) object-sensitive pointer analysis [17], and uses the results to determine the contexts in which to analyze method bodies. Object sensitivity provides context-sensitivity appropriate for object-oriented languages. For example, in the Java program presented in Figure 1, object sensitivity allows our analysis to determine that objects placed in and retrieved from List a are distinct from the objects in List b. King et al. [13] note that exceptions are a major source of imprecision in information-flow security-type systems. Specifically, conservative assumptions about the throwing of runtime exceptions (such as NullPointerExceptions when accessing fields, and ClassCastExceptions when casting objects) produce the vast majority of false warnings in the code they examined. The object-sensitive pointer analysis allows us to reduce significantly the number of such false warnings in two ways. First, we use the results of the pointer analysis to perform an object-sensitive interprocedural null analysis to determine when expressions be null; this significantly reduces the number of NullPointerExceptions that the analysis must conservatively assume are thrown. Second, the pointer analysis computes the precise types of objects that expressions may refer to; this information often suffices to determine that no Class- CastException can be thrown by a cast expression. Our implementation does, however, still suffer from significant amounts of imprecision, including reasoning about IndexOutOfBoundsExceptions, and the termination of loops and recursion. Our implementation is a whole program analysis: we require all source code to be available, and do not currently support modular or incremental analysis. We analyze Java library code, and require sound signatures to 10

11 be provided for native methods. For some of the Java library classes, we do not attempt to analyze the code due to their tight integration into the Java language; instead we rely solely on signatures for the analysis of clients of these classes, which include java.lang.object, java.lang.string, and java.lang.classloader, The programmer must indicate sources of sensitive information and sinks of non-sensitive information. Our current implementation requires programmer annotation, although a possible extension is to infer sources and sinks, for example, by identifying network input and output. The programmer may annotate any expression as a sensitive input, and provide an arbitrary string to label this input. Similarly, any expression may be labeled as an output. The analysis will report the policies inferred for the output expression. 5. Related work In this work, we use a static analysis to infer declassification policies that a program satisfies. Our declassification policies specify strong information-flow security, yet are simple and intuitive. Sabelfeld and Myers [22] survey language-based techniques for static reasoning about information-flow security. We consider two main bodies of related work: specification of declassification policies; and inference of security policies. Declassification policies. Declassification occurs when secret information is made more public. Declassification violates the semantic security condition of noninterference [10], yet commonly (and deliberately) occurs in computer systems that handle sensitive information. Sabelfeld and Sands [24] survey semantic security conditions for declassification, and categorize them conditions based on which of the following aspects of declassification they address: what information may be revealed, when the information may be revealed, who controls the release of information, and where in the system or program the information is released. Our policies specify what information may be declassified, characterized as an expression whose evaluation the attacker may learn. For example, in the policy b 1,..., b n e, the attacker may learn the evaluation of expression e, provided b 1,..., b n all evaluate to true. This is approximately equivalent to the attacker learning the evaluation of the expression if b 1 b n then e else, for some distinguished value. The most closely related security condition is delimited release [23], which uses escape hatch expressions to specify what secret information may be released. Delimited release (and later extensions, including localized delimited release [2] and gradual release [3]) require escape hatch expressions to appear marked with declassify annotations. By contrast, we eschew declassification annotations in favor of inference. Our definition of attacker knowledge is based on that presented by Askarov and Sabelfeld [3]; however, we assume that the attacker can observe only the initial and final stores, and not the sequence of stores the program produces. Our definition of attacker knowledge could be easily adapted for this observational model, or an interactive observational model (such as, e.g., [21]). Our declassification policies induce an equivalence relation that our security condition requires attacker knowledge to respect. Other work also uses equivalence relations to characterize what information a program may reveal. Cohen [6] was the first to use equivalence relations to explicitly model information flow. Zdancewic and Myers [26] present robust declassification (a semantic security condition connecting declassification to integrity) using arbitrary equivalence relations to characterize an attacker s observational abilities. Giacobazzi and Mastroeni [8, 9] use abstract domains to specify these equivalence relations: two initial stores are related if they have the same abstraction. Sabelfeld and Sands [24] also present prudent principles for declassification security conditions. Like delimited release, we satisfy semantic consistency, conservativity, and non-occlusion; the principle of monotonicity of release is not applicable, as our programs have no declassification annotations. Inference of security policies. Backes et al. [4] present an analysis that automatically discovers an equivalence relation characterizing the secret information a program may reveal. By computing the size of the equivalence classes, they can quantify a program s information flow. Their approach, like ours, aims to infer equivalence relations that describe the secret information a program may reveal. We also allow expressions over low security variables. For example, we can infer that a password checking program if guess=password then l := 1 else l := 0 is secure with respect to the policy set {true guess = password}. By contrast, Backes et al. use experiments to describe the possible low inputs, and present security results for a given experiment. For example, for the experiment consists of a single guess, say zero, their analysis determines that the equivalence classes are characterized by password=0 and password 0, and thus it is revealed to the attacker whether password = 0. The need to specify experiments does not seem to be a fundamental limitation of their approach, but highlights the difference in our approach: we seek to infer humanreadable qualitative declassification policies that assist a programmer to understand information flow in her program; these declassification policies do not need to 11

12 be as precise as possible, and it may be desirable to sacrifice precision for understandability. Banerjee et al. [5] suggest model checking to determine if programs satisfy declassification policies expressed as abstraction functions; counter-examples produced by the model checker allow the declassification policy to be refined, and the process repeated, to determine of the least amount of information that a program declassifies. As with Backes et al., we believe the key difference is that our declassification policies represent a better trade-off between precision, intuitiveness, and ease of inference. King et al. [13] statically infer information flows from secret data to public outputs to investigate the precision of security-type checking with respect to implicit information flows. Although they perform a context-sensitive analysis, they infer flow-insensitive types: within a given context, a variable is assumed to always contain information of the same security level. By contrast, we distinguish the contents of a variable at finer granularity, similar to flow-sensitive security types [12]. Liu and Milanova [15, 16] present static analyses to infer explicit information flows in programs. Their implementations appear efficient and practical. However, they do not track implicit flows, and so it is unclear what information security guarantees their analyses provide, which may be inadequate in some settings. For example, an analysis of the password checking program that ignored implicit flows would conclude that the attacker learns nothing about the secret password. Smith and Thober [25] seek to improve the usability of information-flow type systems by performing type-inference for a highly polymorphic object-oriented security-type system. Top-level security policies are specified independently of the code, and the inferred types are used to determine if the program is compliant with the given policy. Their work, like ours, seeks to reduce the programmer burden. However, they aim to simplify enforcement of an explicitly specified security policy, whereas we aim to aid the programmer in understanding information flow in her program. King et al. [14] present a model for information-flow blame that aids the identification of code that violates specified security policies. Their work on informationflow blame aims to help the programmer understand information flows in a program. However, they assume that the program types have been annotated with security policies, and do not attempt to infer security policies that the program satisfies. Thus, they are unable to provide security guarantees if the program fails to type check. 6. Future work and conclusion Strong security guarantees are not free; even with sophisticated tools and techniques, proving that a program handles all information appropriately may require considerable effort by the programmer. However, requiring the programmer to invest a large amount of time and energy before receiving any security guarantees imposes a high barrier to entry. In this work, we explore the inference of declassification policies as a step towards the explicit goal of providing security guarantees that are proportional to programmer effort. We present declassification policies that can specify what information is released under what conditions, and define a semantic security condition that specifies what it means for a program to satisfy these policies. The declassification policies are designed to provide precise and intuitive descriptions of potentially dangerous information flow in a program, and also to be amenable to inference. We define and prove sound an analysis that infers declassification policies for programs in a simple imperative language with exceptions. Thus, a program is guaranteed to be secure with respect to the set of declassification policies output by the analysis. We have extended the analysis to single-threaded Java 1.4 programs, and implemented it as an objectsensitive interprocedural analysis. Mechanisms that provide security guarantees proportional to programmer effort have the potential to be accessible to a broad class of programmers. We see inference of declassification policies as an important step towards such mechanisms. However, much work remains to be done. Ideally, if the programmer is unsatisfied with the security guarantees the analysis provides for the program, she should have two options: provide additional information to the analysis, or modify the program to make it more secure. In our prototype implementation, the programmer does not have an easy mechanism to provide additional information, such as assertions that loops terminate, or that certain runtime exceptions cannot be thrown. Extending our implementation to provide such a mechanism is straightforward. The declassification policies inferred by our analysis are summaries of potentially dangerous flows in a program. Although the policies are intended to be human readable, they are not intended to be used in isolation of the code. Instead, we envision a user interface that allows the programmer to explore and understand these information flows in a program. 12