Required Information Release

Many computer systems have a functional requirement to release information. Such requirements are an important part of a system’s information security requirements. Current information-flow control techniques are able to reason about permitted information flows, but not required information flows. In this paper, we introduce and explore the specification and enforcement of required information release in a language-based setting. We define semantic security conditions that express both what information a program is required to release, and how an observer is able to learn this information. We also consider the relationship between permitted and required information release, and define bounded release, which provides upper- and lower-bounds on the information a program releases. We show that both required information release and bounded release can be enforced using a security-type system.


I. INTRODUCTION
Information-flow control holds the promise of strong, endto-end, application-specific information security [1].To date, most research on information-flow control has focused on what flows are permitted or prohibited in a system.For example, noninterference [2] prohibits confidential inputs flowing to public outputs.
However, many systems have more than just permission to release information; they have an obligation to release information.In this work, we introduce and explore the specification and enforcement of required information release, or simply, required release.
Examples abound of systems with an obligation to release information.The Sarbanes-Oxley Act of 2002 is a United States federal law that was enacted after a series of corporate accounting scandals, and requires publicly held companies to report details of their finances to a government agency.Thus, financial systems of such companies are required to release sensitive financial information to the government agency.Pharmaceutical companies in many countries are required to report all results of clinical trials of new drugs to a government agency (such as the Food and Drug Administration) to receive approval.Computer systems that support the conduct of clinical trials must release all trial results, and not withhold negative results.In general, transparency of organizations and processes requires the release of sensitive information.Other systems that are required to release information include the following.
• Sealed bid auctions: at the end of the auction, the winning bid (and, depending on the auction, the winner's identity) is required to be released.• Information purchase: once a customer has paid for information (such as electronic media), the information is required to be available for download.• Games: legal game-play often requires release of a player's secret information, such as the cards in a player's hand, or the location of battleships on a player's board.• Course management system: when a professor indicates that exam results are available, the system is required to allow students view their grades.• Credit card sales: the receipt for a credit card purchase is required to show the final four digits of the customer's credit card number.In the examples above, the required release of information is an important aspect of each system's information security.To gain assurance in the systems' correct implementation, it is necessary both to specify the required release (and other information security requirements) and to verify that the implementation satisfies the specification.
However, the specification of required release is subtle.What does it mean for a program to satisfy the required release of information?How do we know if a program is successfully and correctly releasing information?It does not suffice for the output of a program to simply depend upon, or be influenced by, the information required for release.Surprisingly, even if the output contains the information required for release, the program may not satisfy the required release of information.We use epistemic logic, and algorithmic knowledge [10] in particular, to guide our definition of required information release.Required information release must specify not just what information is to be released, but also how that information is to be learned by its intended recipient.
Required release is a functional requirement on a system: the output of a program must allow an observer to learn certain information.Required release makes explicit what information the observer learns, and how the observer obtains this knowledge.Noninterference [2] and most other information flow security conditions are not functional requirements.
However, required release is an information flow security condition; it describes a mandatory flow of information to an observer.By contrast, most existing work in information flow considers permitted flows of information.In terms of dependence, permitted information flow conditions restrict how the output is permitted to depend on the inputs.For example, noninterference requires that public outputs do not depend on private inputs-if a private input changes, the public output should not change.Required information release mandates that outputs must depend on inputs in a way that allows an observer to learn certain informationif an input changes, the output must change to allow an observer to learn the specified information.
Required release interacts with permitted information flows in more interesting ways than other functional requirements: if a system is required to release information, then the system must also be permitted to release it.Indeed, required information release and permitted information release can be combined to specify both upper and lower bounds on the information that a system releases.We do so by defining bounded release, a security condition that combines required release and delimited release [11], and thus specifies both what information a program is required to release, and what information it is allowed to release.
For some systems, bounds on information release should be tight.For example, a company producing reports in accordance with the Sarbanes-Oxley Act typically wishes to release no more information than is required by law; thus, the information that their financial system is permitted to release should be identical to the information it is required to release.In other systems, the bounds are not tight, such as in a poker game where some players are permitted, but not required, to reveal their cards at the end of a hand.
The remainder of the paper is structured as follows.Section II uses the example of a simple credit card sales system to examine what it means for a system to satisfy required information release.Section III presents an interactive imperative language that we use in Section IV to formally define required release.We also define bounded release, a security condition that specifies what information a program is required and permitted to release.We show in Section V that required release and bounded release can be soundly enforced in an interactive language by a type system.Section VI discusses related work, and Section VII concludes.

II. WHAT IS REQUIRED RELEASE?
Consider, as a running example, a (grossly simplified) credit card sales system that takes a credit card number as input from high confidentiality channel H, and is required to release the last four digits to low confidentiality channel L (representing, for example, the printer, or an audit log).What does it mean for this system to satisfy the required release of the last four digits?
Noninterference [2] is a strong information security condition that requires that public outputs reveal no information about confidential inputs.Any system that releases confidential information violates noninterference; the credit card sales system, which must release the last four digits of the confidential credit card number to a publicly observable printer, violates noninterference.However, just because a system violates noninterference does not mean it satisfies the required information release.
Consider the following attempt to implement the credit card sales system.
if (cc mod 10, 000) < 5, 000 then output 0 to L else output 1 to L The program inputs the credit card number from channel H, and then outputs either 0 or 1 to channel L. The output observed on channel L is influenced by the last four digits of the confidential input, and thus the program does not satisfy noninterference.However, the program fails to satisfy the required information release, as an observer of channel L does not learn the credit card number's last four digits.Surprisingly, even if a system outputs the information required for release, it may fail to satisfy the required information release.This is demonstrated in the following program, which is another attempt to implement the credit card sales system.P 2 : input cc from H; i := 0; while i < (cc mod 10, 000) do output i to L; i := i + 1; output (cc mod 10, 000) to L; i := i + 1; while i < 10, 000 do output i to L; i := i + 1 The command output (cc mod 10, 000) to L in program P 2 above explicitly outputs the credit card's last four digits.
However, every execution of the program outputs all integers from 0 to 9,999 in order.An observer of channel L always sees the same output, regardless of the credit card's last four digits, and so the observer learns nothing.These examples show that it is insufficient for observable output to be merely correlated with the information required for release, or even for the output to contain that information.
The key insight is that to satisfy required release, the output must allow an observer to know what information was required for release.
In models of knowledge based on possible world semantics [12,13], an agent has implicit knowledge (or, simply, knowledge) of fact φ if in all possible worlds consistent with the agent's observations, φ is satisfied.In the credit card system, an observer of channel L knows the last four digits of the credit card if all credit cards that could have produced the observed output end in the same four digits.Programs P 1 and P 2 do not allow an observer of channel L to know the last four digits.
Standard logical approaches to knowledge suffer from the problem of logical omniscience: an agent knows all logical consequences of its knowledge.The following attempt to implement the credit card system demonstrates this problem.The program chooses two large primes, outputs their product, and the result of XOR-ing the smaller prime with the last four digits of the credit card number (padded with random bits to be the same length as the prime).P 3 : input cc from H; p := generateLargePrime(); q := generateLargePrime(); output p × q to L; if p < q then t := p else t := q; output t xor pad (cc mod 10, 000) to L A logically omniscient observer of the program's output knows what the last four digits of the credit card number are.However, determining this requires factoring a large number, which is beyond the abilities of humans and current computer systems to perform in reasonable time.
Algorithmic knowledge [10] was introduced to address the problem of logical omniscience, and we can use algorithmic knowledge to reason whether a system satisfies required release.
An agent has algorithmic knowledge, or explicit knowledge, of fact φ if the agent has an algorithm that responds "Yes" when given input φ and the agent's observations.The agent's knowledge algorithm is sound if whenever it responds "Yes" then the agent has implicit knowledge of φ, and if the knowledge algorithm responds "No" then the agent does not have implicit knowledge of φ.
Rich classes of knowledge algorithms have been studied that can conservatively overestimate the computational ability of agents without giving the agents logical omniscience (e.g., Ramanujam [14], Pucella [15]).However, we are interested in simple algorithms.Such algorithms may be described in user manuals, specified by a government agency or auditor, or may be inferred from self-explanatory output.In all cases, the aim is to make it easy for an observer to learn the released information.In this setting, the observer is not the adversary, and it is acceptable (even desirable) to underestimate the observer's computational abilities, much as an instruction manual aims to be usable by as wide an audience as possible.For some programs (such as P 3 ), there may be sound knowledge algorithms that are beyond the ability of any observer to execute in reasonable time; such programs do not allow the observer to easily learn the released information, and are thus of no interest to us.For required release, we are concerned with the existence of sufficiently simple sound knowledge algorithms.
The following program does release the last four digits of the credit card number to channel L. P 4 : input cc from H; output "Last 4 credit card digits: " to L; output (cc mod 10, 000) to L Moreover, there is a simple sound knowledge algorithm to provide explicit knowledge for an observer of channel L: given fact φ ≡ (cc mod 10, 000) = n, respond "Yes" if and only if the second output is n.Because there is a simple sound algorithm, an observer can gain explicit (and implicit) knowledge of the last four credit card digits, and so the program satisfies the required information release.
To specify required release, we must specify not only what information is to be released, but also how that information is to be learned.We formalize this intuition by defining required information release in terms of a simple interactive programming language.

III. LANGUAGE
In this section we present a simple interactive imperative programming language due to O'Neill et al. [16].We use an interactive language as it is more general than the batch model traditionally used to reason about language-based information flow, and it can more accurately model real world programs that interact with their external environment, such as server processes, and programs with user interfaces.
We assume set L of security levels, ordered by a reflexive transitive relation that indicates the relative restrictiveness of the levels.In this paper, our examples use the two element set L = {L, H} where L H. Security level L represents low confidentiality, and security level H represents high confidentiality.More expressive security levels are possible (e.g., Myers and Liskov [17], Chen and Chong [18]).Metavariable ranges over security levels.

A. Users, channels, and strategies
Users interact with executing programs.We assume that security levels characterize users: the security level of a user indicates the most restrictive level of information the user is permitted to read.We assume that users with the same security level can freely collaborate, and so, without loss of generality, assume only a single user at each level.
Users communicate with executing programs via channels.We assume input on channels is blocking, and output is non-blocking.We assume that there is a single channel for each user, which, given the assumption of a single user for each security level, implies a single channel for each security level.We thus identify channels with security levels.An event is the transmission of an input or output on a channel.Event in( , v) denotes the input of value v on channel , and event out( , v) denotes the output of value v on channel .For simplicity we restrict values to integers.
We use Ev in and Ev out to denote, respectively, the set of all input and output events.We use Ev( ) to denote the set of all events that could occur on channel , and Ev to denote the set of all events.
where |t| is the length of t.For infinite traces t, we define |t| = ∞.The ith element of event trace t is denoted t(i), for i such that 0 ≤ i < |t|.The empty trace is denoted .We write tˆt for the concatenation of finite trace t and trace t .For traces t and t , we say that t extends t , written t t , when t is a prefix of t.Note that if t is an infinite trace, then t is the only trace that extends it.The set of all traces on E is denoted Tr(E).
The restriction of trace t to E, written t E, is the trace obtained by removing from t all events not contained in E. We write t as shorthand for t Ev( ).
User strategies express the behavior of users by describing how users interact with a program.Given trace t, a user of a channel with security level observes the event trace t Ev( ); a user's observations may influence their subsequent interaction with the program.Formally, a user strategy for a channel with security level is a function of type Tr(Ev( )) → Z, and expresses what input a user will provide given their previous observations.Let UserStrat be the set of all user strategies.A joint strategy is a collection of user strategies, one for each channel.Formally, a joint strategy ω is a function of type L → UserStrat, that is, a function from security levels to user strategies.Let Strat be the set of all joint strategies.
User strategies are sensitive information.In general, we want to ensure that lower security users do not learn about strategies employed by higher security users: user should not learn anything about the strategy of user , where .However, information release will violate this, revealing some information about the strategies of higher security users.In Section IV we will discuss security requirements, and formally define semantic security conditions.

B. Syntax and semantics
We use a simple imperative language, extended with input, output, and declassification commands.The syntax of this language is: A configuration is a 4-tuple (c, σ, t, ω) representing a system about to execute c with state σ and joint strategy ω.Finite trace t is the history of events produced by the system so far.Terminal configurations have the form (skip, σ, t, ω).Metavariable m ranges over configurations.We define a small-step operational semantics for our language, using the relation −→ over configurations.If (c, σ, t, ω) −→ (c , σ , t , ω) then execution of command c can take a single step to command c , while updating the state from σ to σ .Trace t extends t with any events that were produced during the step.Joint strategy ω is unchanged when a configuration takes a step, and is included in configurations to simplify notation and presentation.
Figure 1 presents inference rules for the operational semantics.We use σ(e) to denote the evaluation of expression e where each variable x is replaced with the integer σ(x).Input command input x from takes the next input value v as defined by the user strategy for , assigns it to variable x, and updates the trace with input event in( , v).Similarly, output command output e to evaluates e to v, and updates the trace with output event out( , v).Declassification x := declassify(e to ) is semantically equivalent to assignment x := e; the declassify annotation and security level are used in the type system, described in Section V.
We use −→ * to denote the reflexive transitive closure of −→.For finite trace t, we say configuration m emits t, written m t, if there is some configuration (c, σ, t, ω) such that m −→ * (c, σ, t, ω).For infinite trace t, m emits t if m emits all finite prefixes of t.Note that emitted events may include both input and output events.

IV. SECURITY DEFINITIONS
In this section we define the security conditions weak required release and strong required release, which for-OS-ASSIGN

OS-WHILE
(while e do c, σ, t, ω) −→ (if e then (c; while e do c) else skip, σ, t, ω) OS-DECLASSIFY (x := declassify(e to ), σ, t, ω) −→ (skip, σ[x → σ(e)], t, ω) mally express what it means for a program to satisfy the required release of information.We also present the security conditions noninterference [2] and delimited release [11].Noninterference requires that a program does not release any confidential information.Delimited release weakens noninterference by specifying what confidential information a program is allowed to release.We combine delimited release and required release to define bounds on what a program is permitted and required to release.

A. Required release
To formally define required release, we must be able to express what information is to be released, and how that information is to be learned by an observer.We introduce input expressions and output expressions to express each of these respectively.Input expressions are expressions over input values supplied on channels; output expressions are expressions over values output on a single channel.
The syntax for input and output expressions is: Input expression in [i] refers to the ith input event on channel , for i ∈ N. Input expressions may also contain integer constants and binary operations.Input expressions are evaluated against a trace.The judgment t in f ⇓ v means that with trace t, input expression f evaluates to value v. Evaluation rules for input expressions are given in Figure 2. If t does not have an ith input event on channel , then in [i] evaluates to ⊥, that is, t in in [i] ⇓ ⊥.We assume that any binary operator ⊕ defined is total over Z ⊥ and strict, meaning that for all m, n ∈ Z ⊥ , m⊕n is defined, and if m or n is ⊥, then m ⊕ n = ⊥.
Output expressions are also evaluated against a trace.The judgment t out g ⇓ v means that output expression g evaluates to value v using trace t restricted to channel events.Output expression out[i] refers to the ith output event on channel , for i ∈ N. Figure 2 also presents the evaluation rules for output expressions.Similar to input expressions, if there is no ith output event on channel , then out[i] evaluates to ⊥.
Intuitively, user learns input expression f from command c using output expression g, if in every execution that g evaluates to an integer value (using the output provided to ), then f evaluates to the same integer.Thus, input expression f indicates what information the user is to learn, and output expression g indicates how the user learns it-g provides a sound knowledge algorithm.This leads us to our first definition of required release.
Command c satisfies weak required release of input expression f to user using output expression g if for any trace t that can be emitted by executing c, if t provides enough output to to evaluate g, then f and g evaluate to the same value.
Definition 1 (Weak required release).Command c satisfies weak required release of input expression f to user using output expression g exactly when: and for all traces t such that m t, if t out g ⇓ v and v = ⊥ then t in f ⇓ v.
Program P 4 satisfies weak required release of in H [0] mod 10, 000 to L using out [1]: the second output to L is the last four digits of the first H input (the credit card number).By contrast, programs P 1 and P 2 do not satisfy weak required release of in H [0] mod 10, 000 to L for any output expression.
Weak required release is "weak" in that there is no requirement that command c provide sufficient output to for g to evaluate to an integer value.For example, the program skip satisfies weak required release of any input expression to L using output expression out[0], since no output is ever given to L, and output expression out[0] never evaluates to an integer value.
We can strengthen weak required release to ensure that command c always eventually provides sufficient output to for g to evaluate to an integer value.Command c satisfies strong required release of input expression f to user using output expression g if for any trace t that can be emitted by executing c, there is a trace t that extends t, can be emitted by executing c, and provides sufficient output to to evaluate g, and f and g evaluate to the same value. 1efinition 2 (Strong required release).Command c satisfies strong required release of input expression f to user using output expression g exactly when: For all configurations m = (c, σ, , ω) and for all traces t such that m t, there exists trace t such that t t, m t , and Strong required release is strictly stronger than weak required release: if command c satisfies strong required release of f to using g, then it satisfies weak required release of f to using g.Indeed, weak required release is a form of partial correctness, whereas strong required release is a total correctness condition.The following program satisfies weak required release, but not strong required release of in H [0]mod10, 000 to L using out [1], because in some cases it will never produce sufficient output to L. (For presentation purposes, we assume that constant strings, such as "Last 4 credit card digits: " can be converted to appropriate constant integer values, and output to channels.) output "Last 4 credit card digits: " to L; if cc mod 10 = 0 then (while 1 do skip) else skip; output (cc mod 10, 000) to L Program P 4 satisfies strong required release of in H [0] mod 10, 000 to L using out [1], because it always produces appropriate output to channel L. Connection to explicit knowledge: If a program satisfies (weak or strong) required release of input expression f to user using output expression g, then output expression g provides a sound knowledge algorithm for to learn the value of f .The knowledge algorithm takes as input a formula φ and the sequence of events that has observed.The knowledge algorithm is straightforward: If φ ≡ f = n and t out g ⇓ n then respond "Yes".Otherwise, respond "?".
Note that the algorithm never responds "No", and if the algorithm responds "Yes", then, because the program satisfies required release of f to using g, t out g ⇓ n implies f = n.Thus, the knowledge algorithm is sound.
Strong and weak required release are both parameterized by output expression g.As discussed in Section II, the output expression g may be specified by the consumer of the output (such as an auditor or government agency), an instruction manual, or may be described by the program's output (as in Program P 4 , where the text "Last 4 credit card digits" is output just before the last four credit card digits).In practice, there may be additional requirements on the form of the output function, such as a limit on the number of steps required to evaluate it (analagous to requiring that the instructions for a task be no more than two pages).
Integrity, availability, and properties: Although required information release is primarily concerned with the confidentiality of information, it is also related to the integrity and availability of information.Weak information release is an integrity requirement: if the output expression evaluates to an integer value, it must equal the evaluation of the input expression.Strong information release contains an availability requirement: the output expression must eventually evaluate to an integer value.Information security requirements are not always easily separable into confidentiality, integrity, and availability requirements.
Weak and strong required release can be defined as properties: predicates over single execution traces.Weak required release is a safety property, and strong required release is neither safety nor liveness [19].Recent work by Clarkson and Schneider [20] expresses some informationflow conditions as hyperproperties: predicates of sets of traces.They note that all information-flow conditions they considered were hyperproperties and not properties.Although weak and strong required release are properties, they are clearly constitute part of a systems information flow requirements, so some information-flow conditions of interest are properties.Indeed, in Section IV-C below, we discuss the relationship between required release and delimited release, an information flow security condition for permitted information release that is a hyperproperty and not a property.

B. Noninterference
Noninterference [2] is a well-known semantic security condition that requires that public observations reveal no secrets.Applied to the interactive setting used here, noninterference ensures that user does not gain any knowledge about the strategy employed by any user such that .That is, the strategy of any such user does not interfere with the trace observed by user .
More precisely, a program satisfies noninterference if, for all security levels , and all configurations m and m that agree on the user strategies of all users such that , the traces emitted by m and m are indistinguishable to user .Two traces t and t are indistinguishable to user , written t ≈ t if t extends t , or vice-versa.This notion of trace indistinguishability is suitable given the observational model, which does not allow a user to directly distinguish a terminated program from a program in a nonterminating loop, or from a program that may eventually produce additional output.

Definition 3 (Noninterference). A command c satisfies noninterference exactly when for all levels ∈ L:
For all m = (c, σ, , ω) and m = (c, σ, , ω ) such that ω( ) = ω ( ) for all , and for all traces t, t such that m t and m t , we have t ≈ t .
Note that both weak and strong required release of f to violate noninterference if the input expression f contains an input expression in [i] such that (and the evaluation of f depends nontrivially on in [i]).For example, any program that satisfies (weak or strong) required release of in H [0] mod 10, 000 to L (such as program P 4 ) must violate noninterference, since H L, and L learns something about the strategy of H, to wit, the last four digits of the credit card number that H entered.

C. Delimited and bounded release
Noninterference is a very restrictive security condition.Many real-world programs must violate noninterference in order to satisfy functional requirements that require or allow the release of information.
The security condition delimited release [11] weakens noninterference by specifying what information a program is permitted to release.
An escape hatch is a pair (f, ) of input expression f , and security level .Intuitively, given escape hatch (f, ), a program is permitted to release information f to security level . 2 Thus, given escape hatches (f 0 , 0 ), . . ., (f k , k ), user is permitted to learn the evaluation of f i for any escape hatch (f i , i ) such that i , in addition to the user strategies of any user such that .A program satisfies delimited release by escape hatches (f 0 , 0 ), . . ., (f k , k ) if, for any security level and configurations m and m that have the same user strategy for any user such that , if m and m respectively emit traces t and t that agree on the evaluation of all escape hatches that may release information to level , then the traces emitted by m and m are indistinguishable to user .Formally, we say that traces t and t agree up to on escape hatches (f 0 , 0 ), . . ., (f k , k ) if for all i ∈ 0..k such that i , we have t in f i ⇓ v i and t in f i ⇓ v i for some v i = ⊥.Definition 4 (Delimited release).Command c satisfies delimited release by escape hatches (f 0 , 0 ), . . ., (f k , k ) exactly when for all levels ∈ L: For all m = (c, σ, , ω) and m = (c, σ, , ω ) such that ω( ) = ω ( ) for all , and for all traces t, t such that m t and m t , if t and t agree up to on escape hatches (f 0 , 0 ), . . ., (f k , k ), then t ≈ t .Delimited release generalizes noninterference: if command c satisfies delimited release by an empty set of escape hatches, then c satisfies noninterference.
Both delimited release and required release are concerned with information flow, and with the knowledge an observer acquires.Required release specifies what information, at a minimum, a program must release.It specifies what an observer must be able to (explicitly) know, and can be viewed as specifying "lower bounds" on what information a program releases.By contrast, delimited release specifies what an observer is permitted to (implicitly) know, and can be seen as specifying "upper bounds", the maximum information a program is permitted to release.We can combine the security conditions of delimited release and required release to obtain both upper and lower bounds on a program's information release.
By analogy with escape hatches (which can be defined as openings in the roof of a building, and specify the upper bounds on information release), we use escape chutes (passages down which things may pass) to define the lower bounds of information release.An escape chute is a tuple (f, , g) of input expression f , security level , and output expression g.We define bounded release by combining delimited release by escape hatches, and required release by escape chutes.
Definition 5 (Bounded release).Command c satisfies weak (strong) bounded release by escape chutes and escape hatches (f 0 , 0 ), . . ., (f n , n ) exactly when 1. for all i ∈ 0..k, c satisfies weak (strong) required release of f i to i using g i ; and 2. c satisfies delimited release by escape hatches (f 0 , 0 ), . . ., (f n , n ) Program P 4 satisfies strong bounded release by escape chute (in H [0] mod 10, 000, L, out [1]) and escape hatch (in H [0] mod 10, 000, L).Thus, bounded release tells us not only that P 4 releases the input expression in H [0] mod 10, 000, but also that this is the only information released by P 4 .
The following program has different upper and lower bounds.It satisfies strong bounded release by escape chute (in H [0] mod 10, 000, L, out [1]) and escape hatches (in H [0] mod 10, 000, L) and (in H [0] div 10 15 , L).It always releases the last four digits of the credit card number (via output expression out [1]) and it may in addition release information about the first digit of the (16 digit) credit card number.
P 6 : input cc from H; x := declassify(cc mod 10, 000 to L); output "Last 4 credit card digits: " to L; output x to L; y := declassify(cc div 10 15 to L); if y = 4 then output "Visa" to L else skip There is a consistency property between the escape hatches and escape chutes.Since escape chutes are the "lower bounds" of information release, they must contain no more information than the escape hatches, the "upper bounds" of information release.More precisely, if t and t are traces that can be produced by a command satisfying bounded release, and t and t agree on all input and output events on all channels up to some level , and agree on the value of all escape hatches that declassify to or below, then for each escape chute at level or below, either t and t agree on the value of the escape chute, or t and t do not have sufficient input events to evaluate the escape chute.We say that traces t and t agree on escape chute Property 1 (Consistency).If command c satisfies (weak or strong) bounded release by escape chutes (f 0 , 0 , g 0 ), . . ., (f k , k , g k ) and escape hatches (f 0 , 0 ), . . ., (f n , n ) then for all ∈ L, and for all configurations m = (c, σ, , ω) and m = (c, σ, , ω ), and for all traces t, t such that m t and m t , if t and t agree up to on escape hatches (f 0 , 0 ), . . ., (f n , n ), and for all we have t = t then for all i ∈ 0..k such that i , either t in f i ⇓ ⊥, or t in f i ⇓ ⊥, or t and t agree on escape chute (f i , i , g i ).
Proof: (Sketch) Given and t and t such that t and t agree up to on escape hatches (f 0 , 0 ), . . ., (f n , n ), and t = t for all , then we can construct joint user strategies ω and ω such that m t and m t , and ω( ) = ω ( ) for all .For any escape chute (f i , i , g i ) such that i , suppose t 0 i out g i ⇓ v i and t 0 i out g i ⇓ v i for some v i , v i = ⊥.By delimited release, t ≈ i t , and so, t and t agree on the values of all output expressions required to evaluate g i to an integer value.Therefore, v i = v i .By bounded release, the evaluation of f i in t and t also equal v i , and so and t and t agree on escape chute (f i , i , g i ).
V. ENFORCEMENT In this section we show that weak bounded release can be soundly enforced with a security type system.Weak bounded release is the conjunction of weak required release, and delimited release.Since weak required release is a safety property, clearly other enforcement mechanisms could also be used to enforce it, including dynamic mechanisms such as execution monitors.However, due to the similarity of escape chutes and escape hatches, a type system to enforce delimited release can easily be adapted to enforce weak bounded release as well.
Our type system conservatively tracks both the security level of information as it flows through a program, and what Security level typing context Γ maps variables to security levels, and indicates an upper bound on the information stored in each variable.Program counter level pc is an upper bound on the information that may cause command c to be executed, and is used to track implicit information flows [21].Typing context Γ and program counter level pc are standard in security type systems.Our type system is flow-sensitive, as it allows command c to modify Γ, and is based on the flow-sensitive security type system of Hunt and Sands [22].
The remaining entities in the context (C, ∆, E, and H) are used to track what input expressions have been output and declassified.Specifically, we conservatively track how many input and output events have been produced on each channel, what input expression (if any) is stored in each variable, what input expressions (if any) have been output, and what input expressions have been declassified.
• C : L → Z ⊥ ×Z ⊥ counts the input and output events that have occurred on each channel.If C( ) = (i, j), then the program has received i input events from channel , and produced j output events to channel .If i = ⊥, then an unknown number of input events have been received on channel , and similarly, if j = ⊥, an unknown number of output events have been produced.
sion is stored in each variable.For any variable x, if ∆(x) = f then the value stored in x is equivalent to input expression f .If ∆(x) = ⊥ then nothing is known about the value stored in x.
expressions have been output to channels. 3If E( , i) = f then the ith value output on channel was equal to the evaluation of input expression f .If E( , i) = ⊥ then either the ith output to channel has not yet been produced, or nothing is known about the ith output to channel .• H : ℘(InputExp × L) is a set of escape hatches that may have been declassified.Figure 3 presents inference rules for the typing judgment.Given a function h, we write h[a → b] for the function that evaluates to b on input a, and otherwise behaves like h.We use Γ(e) to denote an upper bound of all levels Γ(x) for variables x occurring in e; if L is a join semi-lattice, then this is the join of all Γ(x) for x in e.We extend function ∆ to a homomorphism on program expressions, and write ∆(e) for the result of applying the homomorphism to expression e.
In the typing rules, security level context Γ and program counter level pc do not interact with other parts of the context, and by themselves form a standard flow-sensitive information-flow security-type system, similar to that of Hunt and Sands [22].In the following discussion of the typing rules, we focus on the type system's novel aspects. 3"E" is the uppercase " ", the Greek letter epsilon.
substOutExp(E, , n) = n substOutExp(E, , g 0 ⊕ g 1 ) = substOutExp(E, , g 0 ) ⊕ substOutExp(E, , g 1 ) substOutExp(E, , out[i]) = E( , i) context ∆ using helper function recordInput(∆, x, C, ), which updates ∆(x) either to ⊥ if the number of input events on channel is not known, or to input expression in [i], where i is the number of input events received on channel .If known, the number of input events on channel is incremented using the helper function inc in (C, ).
Command output e to outputs expression e to channel .Using helper function recordOutput(E, C, , f ), rule T-OUT records that the jth output on channel is equal to input expression ∆(e), where j is the number of output events produced on channel , and increments the number of output events produced on channel with helper function inc out (C, ).If the number of output events produced on channel is unknown (i.e., j = ⊥), then no update to E or C is made.
The The rules for if and while commands (T-IF and T-WHILE respectively) type check their sub-commands with a program counter level bounded below by pc and Γ(e), since e controls the execution of the sub-commands.Rule T-WHILE requires that context is unchanged by the execution of the while command; for any channel , this means either that the loop body performs no input or output on , or that the context cannot precisely track the number on inputs or outputs received on channel , i.e., C( ) = (i, j) and ⊥ ∈ {i, j}.
Similarly for an if command, the context will lose track of the number on inputs or outputs received on channel unless both branches always perform the same number of inputs and outputs on .
The type system can easily be converted into an algorithmic type system, using the same technique as Hunt and Sands [22].If the security levels L and binary relation form a join-semi lattice, then type checking and type inference with the algorithmic type system is decidable in time polynomial in the size of the program.
If command c is well-typed, then it satisfies both weak required release, and delimited release.Theorem 1 below states this claim formally.To state Theorem 1 concisely, we first introduce a helper function and additional notation.
Helper function substOutExp(E, , g) takes output con-text E, security level , and output expression g, and substitutes any occurrence of out[i] with input expression E( , i), that is, the input expression that E claims was the ith output on channel .For example, if E((L, 2)) = in H [1], then substOutExp(E, L, 42 + out [2]) = 42 + in H [1]. Rules for substOutExp(E, , g) are given in Figure 4.
We assume there is a notion of equivalence between input expressions, denoted by ≡.We require that if f 0 ≡ f 1 , then for all traces t and v ∈ Z ⊥ , t in f 0 ⇓ v iff t in f 1 ⇓ v.The equivalence relation could be syntactic identity, or syntactic identity up to commutativity and associativity of operators, or, (depending on the operators in the language) a deeper semantic equivalence.
Finally, for any set S and v ∈ S, we use v as shorthand for a constant function that always returns v.For example, (0, 0) is a function that always returns the pair (0, 0).Theorem 1.If pc, Γ 0 ; (0, 0), ⊥, ⊥, ∅ c Γ; C, ∆, E, H for some Γ 0 and pc, then 1. c satisfies weak required release of input expression f to user using output expression g if substOutExp(E, , g) ≡ f .2. c satisfies delimited release by escape hatches (f 0 , 0 ), . . ., (f k , k ) if for all (f, ) ∈ H there exists i ∈ 0..k such that f ≡ f i and i .
A proof of Theorem 1 appears in the companion technical report [23].
If command c is well-typed, then because it satisfies both weak required release, and delimited release, it satisfies weak bounded release.
Proof: Immediate from Theorem 1.Although program P 4 satisfies bounded release, it does not type-check: it attempts to release information from H to L but does not have any declassify annotations.Program P 6 does type-check.The judgment Thus, by Corollary 1, P 6 satisfies weak bounded release by escape chute (in H [0] mod 10, 000, L, out [1]) and escape hatches (in H [0] mod 10, 000, L) and (in H [0] div 10 15 , L).
A more sophisticated static analysis (or a more restrictive language) could enforce strong required release, by reasoning about the termination of loops, and the eventual production of outputs.

VI. RELATED WORK
Much recent work has considered information release.Sabelfeld and Sands [6] present a survey of work on (permitted) information release, and introduce four aspects of declassification: who, what, where and when.These aspects are also relevant to required information release.This work is primarily concerned with what information is required for release, expressed using input expressions.Strong required release relates to the when aspect: it mandates that information is eventually released, whereas weak required release places no requirements on when (if ever) information is released.
Sabelfeld and Sands [6] also introduce several prudent principles of declassification.Of these principles, semantic consistency is directly applicable to required release, and is satisfied by weak and strong required release, and bounded release: semantically equivalent programs satisfy the same security conditions.The other principles do not seem directly applicable to required release.
Previous work on specification and enforcement of information release focuses on permitted information release.To the best of our knowledge, this work is the first to address required information release.Appropriate extensions to the policies and enforcement mechanisms of previous work may allow them to reason about required release.The automata for information release of Swamy and Hicks [8], and the flowspecs used by Banerjee et al. [9] seem particularly suitable for extending for required release.
Askarov and Sabelfeld [24] introduce localized delimited release, which refines delimited release by restricting not only what information may be released, but where it may be released (at an appropriate declassify command).The type system used by Sabelfeld and Myers [11] to enforce delimited release also enforces localized delimited release, so we speculate that the type system used in this paper to enforce bounded release would also enforce an appropriately defined localized bounded release.
Askarov and Sabelfeld [25] define the semantic security condition gradual release in terms of attacker knowledge: an attacker's knowledge of secrets may become more precise only at specified declassification events.Gradual release restricts permitted information release, and as such it suffices to use implicit knowledge; since we are concerned with required release, we use algorithmic knowledge to ensure that knowledge can be obtained with reasonable resources.The use of algorithmic knowledge leads us to specify how an observer learns released information, in addition to what information they learn.
Askarov and Sabelfeld [26] present semantic security conditions that generalize localized delimited release and gradual release, and consider their enforcement using a combination of static and dynamic techniques in an interactive language.Since weak required release is a safety property, it could be enforced using dynamic techniques, such as execution monitors [27].
O'Neill [28] presents many information flow conditions in an epistemic framework, but doesn't consider algorithmic knowledge or required information release.
As discussed in Section IV-A, required information release is concerned with the integrity and availability of information, in addition to its confidentiality.Zheng and Myers [29] study the end-to-end enforcement of availability policies, and present a policy framework for specifying confidentiality, integrity, and availability policies.Their policies are based on the decentralized label model [30], and specify who may affect the confidentiality, integrity, and availability of information.By contrast, this work focuses on what aspects of availability and integrity: what information must be available, and what it must be equal to.

VII. CONCLUSION
As part of their correct functionality, many systems are required (not just permitted) to release information.This paper introduces the problem of required information release: specifying, reasoning about, and enforcing, the information security of systems that must release information.
We have defined semantic conditions for required information release.Inspired by work on algorithmic knowledge, the semantic conditions must specify both what information is to be released, and how that information is to be learned by an observer.Input expressions specify what information is to be released, and output expressions specify how an observer learns the information.A program satisfies weak required release of input expression f to user using output expression g if whenever user is able to evaluate g, then f evaluates to the same value.A program satisfies strong required release if it satisfies weak required release, and eventually produces sufficient output for user to evaluate g.
We investigated the relationship between a system's required and permitted information release, and defined bounded release, which combines required release with delimited release.Bounded release specifies upper and lower bounds on the information a system releases.For many systems, these bounds should be tight: the system should release all and only information it is required to release.We have shown that (weak) bounded release can be conservatively enforced by a type system.
Both weak and strong required release are properties: predicates over single execution traces.Noninterference, delimited release, and many other information security requirements, are hyperproperties, but not properties.One may thus be concerned whether required information release is an information security requirement.We believe that required information release, while a property, is clearly concerned with the flow of information in a system: it requires that, at a minimum, certain information flows to an observer.We have shown a connection between required information release and delimited release: whereas required information release specifies the minimum information flow from high security inputs to low security outputs that a system must satisfy, delimited release specifies maximum information flow.Thus, we believe that required information release is part of a system's information security requirements.
There is still much left to understand with respect to required information release.There are systems with information release requirements that cannot be expressed using the policies presented in this paper.For example, financial reports of a company should be released to all shareholders, not a subset; if Alice and Bob are the shareholders, the system must release reports to Alice if and only if it releases that information to Bob.In terms of enforcing required information release, it may be impractical to explicitly specify the knowledge algorithm by which an observer may learn the released information; static analyses may allow the automatic discovery of the knowledge algorithm, thus reducing the burden of proving a system satisfies required information release.
To build trustworthy computer systems, it is important to understand and provably enforce a system's information security requirements.By introducing the concept of required information release, and providing mechanisms to specify and enforce these requirements, this work brings us closer to the goal of strong, end-to-end, application-specific information security.

(
expressions) e ::= n | x | e 0 ⊕ e 1 (commands) c ::= skip | x := e | c 0 ; c 1 | if e then c 0 else c 1 | while e do c | input x from | output e to | x := declassify(e to ) Metavariable x ranges over Var, the set of all program variables.Variables take integer values, and literal values n also range over integers.Metavariable ⊕ ranges over total binary operations on the integers.A state σ maps variables to values, and so is a function of type Var → Z.

Figure 2 .
Figure 2. Evaluation rules for input and output expressions

Figure 3 .
Figure 3. Typing rules For assignment x := e, T-ASSIGN updates input expression context ∆ for x to ∆(e), which is either ⊥ or an input expression equal to e at this program point.The typing rule T-DECLASSIFY for declassification x := declassify(e to ) is similar to assignment, but escape hatch (∆(e), ) is added to declassification effect H. Note that the rule implicitly requires ∆(e) = ⊥ since H must contain escape hatches.Rule T-SEQ simply threads the context through a sequence of commands.A skip command has no effect on the context, shown in rule T-SKIP.Command input x from assigns the next input from channel to variable x.Rule T-IN updates input expression

Figure 4 .
Figure 4. substOutExp(E, , g) subsumption rule T-SUB allows the context to be weakened, or made less precise.It uses the flat ordering : for any lifted set S ⊥ , and for any a, b ∈ S ⊥ , a b iff a = b or b = ⊥.We extend the relation in the obvious way to pairs, and to a pointwise relation over functions.For example, ∆ 0 ∆ 1 iff for all x ∈ Var, ∆ 0 (x) ∆ 1 (x).Similarly, we extend the binary relation over L to a pointwise relation over functions with codomain L.