Gradual Release: Unifying Declassification, Encryption and Key Release Policies
Aslan Askarov Andrei Sabelfeld Department of Computer Science and Engineering Chalmers University of Technology 412 96 Göteborg, Sweden
Abstract tion release, exposing the other aspects for possible attacks. It is striking that these approaches fall into two mostly sep- Information security has a challenge to address: en- arate categories: revelation-based (as in information pur- abling information-flow controls with expressive informa- chase, aggregate computation, moves in a game, etc.) and tion release (or declassification) policies. Existing ap- encryption-based declassification (as in sending encrypted proaches tend to address some aspects of information re- secrets over an untrusted network, storing passwords, etc.). lease, exposing the other aspects for possible attacks. It It is essential that declassification policies support a combi- is striking that these approaches fall into two mostly sep- nation of these categories: for example, a possibility to re- arate categories: revelation-based (as in information pur- lease the result of encryption should not be abused to release chase, aggregate computation, moves in a game, etc.) and cleartext through the same declassification mechanism. encryption-based declassification (as in sending encrypted This paper introduces gradual release, a policy that uni- secrets over an untrusted network, storing passwords, etc.). fies declassification, encryption, and key release policies. This paper introduces gradual release, a policy that uni- As we explain below, the latter is not only a useful fea- fies declassification, encryption, and key release policies. ture, but also a vital component for connecting revelation- We model an attacker’s knowledge by the sets of possible se- based and encryption-based declassification. We model an cret inputs as functions of publicly observable outputs. The attacker’s knowledge by the sets of possible secret inputs essence of gradual release is that this knowledge must re- as functions of publicly observable outputs. The essence of main constant between releases. Gradual release turns out gradual release is that this knowledge must remain constant to be a powerful foundation for release policies, which we between releases. Gradual release turns out to be a powerful demonstrate by formally connecting revelation-based and foundation for release policies, which we demonstrate by encryption-based declassification. Furthermore, we show formally connecting revelation-based and encryption-based that gradual release can be provably enforced by security declassification. types and effects. When it comes to handling encryption, there is a demand for expressing rich policies beyond declassification at the point of encryption. To this end, a desirable ingredient in 1 Introduction declassification policies is reasoning about released keys. In bit commitment, premature revelation of the bit should Information security [32] has a challenge to address: be prevented by not releasing the secret key until neces- enabling information flow controls with expressive infor- sary. In a media distribution scenario—when large media mation release (or declassification) policies [32, 42, 34]. In is distributed in encrypted form, and the key is supplied on a scenario of systems that operate on data with different the date of media release—early key release should be pre- sensitivity levels, the goal is to provide security assurance vented. In addition, key release policies are important for via restricting the information flow within the system. mental poker [35, 9, 4] (for playing poker without a trusted However, allowing no flow whatsoever from secret (high) third party), where the participants reveal their keys for each inputs to public (low) outputs (as prescribed by nonin- other at the end of the game, in order to prove that they were terference [16]) is too restrictive because many systems not cheating during the game. In this protocol too, it should deliberately declassify information from high to low. not be possible to release secret keys prematurely or encrypt Characterizing and enforcing declassification policies is with a key that has already been released. the focus of an active area of research [34]. However, exist- Gradual release allows for reasoning about newly gener- ing approaches tend to address selected aspects of informa- ated and released keys. In fact, this combination turns out to
In Proc. IEEE Symposium on Security and Privacy, Berkeley/Oakland, CA, May 2007. © IEEE be crucial for connecting revelation-based and encryption- Low-equivalence Memories are mappings of variable based declassification. We show that gradual release for names to values. Two memories M1, M2 are low-equivalent revelation-based declassification can be represented by a with respect to a security environment Γ if ∀x . Γ(x) v rewardingly simple encryption-based declassification: de- L =⇒ M1(x) = M2(x). This is denoted as M1 ∼Γ M2. classifying an expression corresponds to encrypting the ex- pression with a fresh key and immediately releasing the key. Semantics and low events As is standard, expressions As a result, gradual release is, to the best of our knowl- evaluate according to rules of the form hM, ei ⇓ n, where edge, the first framework to unify revelation-based and hM, ei is a configuration consisting of the memory M and encryption-based declassification policies. Furthermore, we the expression to evaluate e, and n is the resulting value. show that gradual release can be provably enforced by se- Semantics for commands are expressed by small-step curity types and effects. transitions between configurations. These transitions have Structure-wise, Section 2 introduces gradual release, il- either the form hM, ci −→α hM 0, c0i, which corresponds to a lustrates its properties, and shows how to enforce it by a step from configuration hM, ci to configuration hM 0, c0i, or security type system for a simple declassification-enabled ↓ the form hM, ci −→ M 0, which corresponds to termination language. Section 3 enriches the language with key gen- in the memory M 0. eration, encryption, and key release primitives. Section 4 A transition is low if it is due to an assignment to a applies gradual release to the enriched language. Section 5 low variable or termination. The event α ∈ {², `} records presents a type and effect system that enforces gradual re- whether the transition is low (reflected by the label `, where lease for the enriched language. Section 6 provides useful ` is either the projection M 0 of the low part of M 0 or a ter- examples of typed programs. Section 7 discusses related L mination event ↓) or otherwise (reflected by the empty label work, and Section 8 concludes. ~` ~` ²). We write hM, ci −→∗ hM 0, c0i (resp. hM, ci −→∗ M 0) when hM 0, c0i (resp. M 0) is reachable from hM, ci by a se- 2 Gradual release quence of small steps, where ~` represents the sequence of generated low events. We classify the termination event ↓ Gradual release is a general notion, defined in terms of as low. If an event in a sequence is a termination event, then events (which are classified into low and high, with some no other events may be generated after it. of the low ones classified as release events). Of particu- A particular kind of low events are due to declassify lar interest are language-based instantiations of this model, commands. We refer to those events as release events. Re- where events are generated by program constructs. A direct lease events record the points of intentional information re- benefit of such instantiations is the possibility of enforc- lease by a command. The complete semantics of the lan- ing gradual release by static analysis. To be concrete (but guage is available in an accompanying technical report [5]. without loss of generality), we present gradual release for a simple imperative language with declassification. We show Knowledge We let the attacker observe the low projec- that gradual release is a conservative extension of noninter- tion M 0 of the initial memory M 0, and all intermediate ference and demonstrate how to provably enforce gradual L low events `1, . . . , `n generated during a run of a command release by a security type system. c. Given these observations, the attacker may infer the set of initial memories that could possibly have led to these events. We refer to this set as the attacker’s knowledge about Language Figure 1 presents the syntax of the language, the initial memory. which contains expressions e and commands c. For sim- Semantically, the knowledge is a set of tuples, where plicity, we assume that variables are assigned one of the each tuple represents a possible initial memory. For exam- two security levels: L (low) or H (high), forming a simple ple, consider the program l := h + h and a sample run security lattice, where L @ H. These levels are recorded in 1 2 that yields a low event ` where `(l) = 10. The attacker’s the security environment Γ, a mapping from variable names knowledge in this case is all such memories that the sum of to security levels. The construct declassify(e) in an as- h and h is 10: signment is provided for declassifying the level of e to L. 1 2
h1 h2 ... e ::= n | x | e op e { (1, 9,... ) c ::= skip | x := e | c; c | if e then c else c (2, 8,... ) | while e do c | x := declassify(e) (3, 7,... ) (4, 6,... ) Figure 1. Simple imperative language ... }
2 Note that in our terminology knowledge corresponds to un- Noninterference We present a definition of noninterfer- certainty about the tuples in the knowledge set: any of the ence and demonstrate how to represent it in the knowledge- tuples is a possible input. The actual knowledge of the at- based setting. tacker is that tuples outside the knowledge set are not pos- sible inputs. Definition 1 (Noninterference). A command c satisfies non- `~1 As the computation progresses, the uncertainty might de- ∗ 0 interference if whenever M1 ∼ M2, hM1, ci −→ M1, crease because new observations might render some initial Γ `~2 ∗ 0 ~ ~ 0 0 inputs impossible. This means that the knowledge set may and hM2, ci −→ M2 then `1 = `2 (and M1 ∼Γ M2). shrink with time. 0 The definition requires that when starting with low- Let L(c, ML ) be the set of possible low event sequences that a program c may generate along terminating traces that equivalent memories, terminating traces must agree on their start in some memory whose low projection is M 0: low events (and, as a consequence, on the low parts of the L resulting memories). This corresponds to the absence of ~` flows from high to low data. 0 ~ 0 0 ∗ 0 L(c, ML ) , {` | ∃M,M .ML = ML ∧hM, ci −→ M } We show that this flavor of noninterference is straight- forwardly expressible in the knowledge-based setting: Based on a program c, a low projection of the initial mem- 0 ory ML , and a (possibly empty) sequence of low events Proposition 2. A command c satisfies noninterference if ~ b 0 b 0 ` ∈ L(c, ML ), where L(c, ML ) denotes the prefix closure and only if of L(c, M 0), the knowledge is defined as: L 0 ~ 0 0 ~ 0 ∀ML , ` ∈ L(c, ML ) . k↓(c, ML , ` ) = k(c, ML ) 0 ~ 0 0 0 k(c, ML , ` ) , {M | ML = ML ∧ ∃M , c . The proposition states that the attacker’s knowledge does ~` ~` hM, ci −→∗ hM 0, c0i ∨ hM, ci −→∗ M 0} not benefit from observing a run of a noninterfering pro- 0 gram: all memories that agree with ML on the low part are This set records all possible inputs that lead to observ- possible inputs regardless of the observed low events ~`. ing ~` when starting with initial memories that agree with 0 ML on the low variables. This definition of knowledge is Gradual release With every new low event produced by termination-sensitive (cf. [32]) because observing that pro- a program run, the attacker’s knowledge may become more gram does not enter an infinite loop may lead to refining the precise, i.e., the set of possible initial memories may be- knowledge. come smaller. The only intentional points when this knowl- Given a command c and the low projection of a mem- edge may be narrowed down are the release events, as spec- 0 0 ory ML , we also define the initial knowledge k(c, ML ) that ified by declassification primitives. Gradual release accepts corresponds to all possible initial memories that lead to ter- changes in the knowledge that are caused by the release mination: events and requires that no other low events may affect the ~` knowledge. 0 0 0 ~ ∗ 0 k(c, M ) , {M | ML = M ∧ ∃M , ` . hM, ci −→ M } L L Definition 2 (Gradual release). A command c satisfies grad- 0 ~ 0 ~ Using this definition, we define a termination-insensitive ual release if for all ML and ` ∈ L(c, ML ), where `n =
(cf. [32]) version of knowledge as: `1, . . . , `n, n ≥ 1, of which `r1 , . . . , `rm are all release events, we have: 0 ~ 0 ~ 0 k↓(c, ML , `) , k(c, ML , `) ∩ k(c, ML ) ∀i . 1 ≤ i ≤ n . (∀j . r 6= i) =⇒ As we expect, the attacker may not “forget” the knowl- j 0 ~ 0 ~ edge about the initial states, i.e., each new observable event k↓(c, ML , `i−1) = k↓(c, ML , `i) may only refine the knowledge: 0 ~ 0 where, as before, k↓(c, ML , `0) , k(c, ML ). The gradual Proposition 1 (Monotonicity of knowledge). For a com- release requirement on the evolution of knowledge is illus- 0 ~ 0 ~ mand c, some ML , and `n ∈ L(c, ML ), where `n = trated in Figure 2, where the vertical axis is uncertainty, and `1, . . . , `n, we have the horizontal axis is time. 0 ~ 0 ~ In the examples throughout the paper, variables l, l1,... ∀i . 1 ≤ i ≤ n . k↓(c, ML , `i−1) ⊇ k↓(c, ML , `i) and h, h1,... are assumed to be low and high, respectively. 0 ~ 0 Examples of programs that are rejected by gradual release where k↓(c, ML , `0) , k(c, ML ). The proofs of this and the following results are available in an accompanying tech- are: nical report [5]. l := h
3 h2 := h1; l2 := h2 Note that at the point of declassification, the attacker learns nothing about the value of h2. However, after reaching the assignment l2 := h2 the attacker’s knowledge will allow inferring the value h2. This is rejected by the release policy because the assignment l2 := h2 is not a declassification. Compared to several where definitions, gradual release Figure 2. Gradual release does not rely on state resetting in-between transitions. Con- sider, for example, the following program: l := declassify (h); where the knowledge is narrowed down from all possible l := h; high inputs to exactly one, and: This innocent program is a false negative for the intransitive if h then l := declassify(h1) downgrading [27], non-disclosure [2], flow locks [8], and where the knowledge is narrowed down to memories where WHERE [26] definitions. These definitions reject the pro- h is zero in the case when no low events are observable gram above because they demand security in the presence before termination. of state resetting. The program is rejected by them because Examples of programs that are accepted by gradual re- resetting the secret state after declassification may reintro- lease are: duce secret into h before it is assigned to l. However, the l := declassify(h) program is secure according to gradual release because the attacker does not gain any new knowledge from observing where the release event due to declassification justifies the the effect of the last assignment. change in the knowledge, and: As a sanity check for our definition, we show that for l:=declassify(h != 0); if l then l1 := declassify(h1) programs without release, gradual release is equivalent to where the non-zero test expression is explicitly released be- noninterference. This property is known as the conserva- fore the choice whether to declassify h1 is made. tivity principle of declassification [34]. The principle fol- In contrast to some declassification definitions (e.g., [10, lows from Proposition 2 and because the attacker’s knowl- 33], but in agreement with others (e.g., [29]), gradual re- edge for declassification-free programs must remain con- lease assumes that the attacker observes more information stant over the execution of the program. about traces (namely, effects of assignments to low vari- ables) than visible initial/final values. Moreover, the at- Proposition 3. If a command c is free of declassification tacker observes some events produced by partial program then c satisfies gradual release if and only if c satisfies non- executions. This enables natural extensions to languages interference. with input/output: low assignments can be viewed as im- plicit output on a low channel. Note that breaches in se- A final remark on the dimensions: although gradual re- curity due to events that are not happening are caught by lease is primarily a where policy, it can be also viewed as a gradual release thanks to termination events. Recall that in relative what policy. Indeed, what attacker learns remains the second insecure example above, if the only observable constant with respect to the last release point. Further, it event by the attacker is termination, then the attacker may is possible to fully integrate the what dimension into grad- deduce that the assignment in the conditional did not hap- ual release. Assume a knowledge evolution sequence that pen, and that the initial value of h must be zero. is provided explicitly as a policy (for example, in terms of In a recent classification of declassification [34], release escape hatch expressions as in delimited release [33]). In policies are classified with respect to the what, who, where, addition to the demand on constant knowledge in-between and when dimensions of declassification. Under this classi- releases, an enhanced policy might require that each refine- fication, gradual release is primarily a where policy because ment of knowledge is in strict accordance with what can be it emphasizes that release is only allowed via declassifica- learned from observing the respective escape hatch expres- tion points. This allows us capturing some flows that are sion from the sequence in the policy. not represented by other dimensions. For example, the fol- lowing program is accepted by pure what definitions such Enforcement It is straightforward to enforce gradual re- as delimited release [33] that ignore the where aspect: lease by a security type system. Figure 3 presents the typing h1 := h2; h2 := 0; rules for expressions and commands. The rules for catch- l1 := declassify (h2); ing explicit and implicit flows are standard [12, 39]. The
4 values, whereas a key at level low key (LK) may only safely Γ(x) = σ (T-INT) (T-VAR) encrypt low values. Keys at level RK correspond to the pre- Γ ` n : L Γ ` x : σ viously secret keys that have been released and may only
Γ ` e1 : σ1 Γ ` e2 : σ2 safely encrypt public values. (T-OP) Γ ` e1 op e2 : σ1 t σ2 Basic types t consist of integers int and ciphertexts encγ τ obtained by encrypting data of primitive type τ with (T-SKIP) Γ, pc ` skip keys at level γ. Primitive types τ consist of basic types la- Γ ` e : σ pc t σ v Γ(x) beled with security levels t σ, key types key γ, and pairs (T-ASGN) (τ, τ) of primitive types. Γ, pc ` x := e Apart from expressions for encryption and decryption, Γ, pc ` c1 Γ, pc ` c2 (T-SEQ) expressions are standard: integers, variables, total binary Γ, pc ` c1; c2 operators, pair formation, and projection. Commands in- Γ ` e : σ Γ, pc t σ ` ci i = 1, 2 clude the standard commands of an imperative language, a (T-IF) Γ, pc ` if e then c1 else c2 command for generating a new key at a given security level, Γ ` e : σ Γ, pc t σ ` c and a command for releasing keys. (T-WHILE) We assume that all variables x used in program text are Γ, pc ` while e do c typed with primitive types according to a typing environ- pc v Γ(x) (T-DECL) ment Γ as x : Γ(x). We also define the low projection ΓL of Γ, pc ` x := declassify(e) the typing environment, which only includes low variables.
Figure 3. Type rules for the simple language Semantics First we define values and environments, which are used in the following definitions of the seman- tics for expressions and commands. Let n ∈ Z range over only non-standard rule is (T-DECL), which disallows de- integers and k ∈ Key = KeyLK ∪ KeyHK range over keys, classification inside of conditionals and loops with sensi- where Key and Key are disjoint. We assume that re- tive guards. We call such a conditional or loop high context LK HK leased keys belong to the set of high keys KeyHK. Values and track it with the context type variable pc. By requiring are built up by ordinary values: integers, keys, and pairs of pc v Γ(x) at declassification points, we ensure that if pc is values; together with encrypted values u ∈ U = ULK ∪ UHK. H then we might be inside a high context, and, hence, we may not assign the result of declassification to a variable at values ∈ Value v ::= n | k | (v, v) | u level L. Note that no information about the declassified expres- The system is parameterized over two symmetric en- sion e is used in the rule for declassification (T-DECL). This cryption schemes—one for the low key level γ = LK, and is sensible because gradual release is a where policy, not a one for the high key level γ = HK—represented by triples what policy, and so the value (and even the syntax) of the SEγ = (Kγ , Eγ , Dγ ), where declassified expression is unimportant. That the type system enforces gradual release is guaran- • Kγ is a key generation algorithm that on each invoca- teed by the following theorem: tion generates a new key.
Theorem 1. If Γ, pc ` c then c satisfies gradual release. • Eγ is a nondeterministic encryption algorithm that takes a key k ∈ Keyγ , a value v ∈ Value and returns 3 Language with cryptographic primitives a ciphertext u ∈ Uγ . and key release • Dγ is a deterministic decryption algorithm that takes a key k ∈ Key , a ciphertext u ∈ U and returns a This section presents an enriched language that includes γ γ value v ∈ Value or fails. Decryption should satisfy cryptographic primitives and key release features. Dγ (k, Eγ (k, v)) = v.
Syntax Figure 4 displays the syntax of the language, The reason for the use of different encryption schemes which is based on the one presented in [3]. Values and keys for different security levels is to lay the ground for exten- have corresponding security levels. Values are either low sions to systems with more than two security levels. In such (L) or high (H). The key levels declare the maximum value a system we would have one encryption schema at each se- security level the key can safely encrypt. In particular, a curity level, trusted to encrypt values up to and including key at level high key (HK) may safely encrypt low and high the security level.
5 sec. levels σ ::= L | H basic types t ::= int | encγ τ key levels γ ::= LK | HK | RK prim. types τ ::= t σ | key γ | (τ, τ)
e ::= n | x | e op e | encryptγ (e, e) | decryptγ (e, e) | (e, e) | fst(e) | snd(e) c ::= skip | x := e | c; c | if e then c else c | while e do c | newkey(x, γ) | release(e)
Figure 4. Enriched language
As stated above, the key sets KeyLK and KeyHK of the not have a declassification construct, we show how to model two different encryption schemes are distinct. We assume revelation-based declassification using key generation, en- that lk ranges over KeyLK and hk over KeyHK. cryption, key release, and decryption. We formally connect The full environment (or, simply, environment) E is a this model to gradual release in the simple language from tuple (M, G, R), where the memory environment M is a Section 2. mapping from variable names to values; the key-stream en- vironment G is a mapping from key levels to streams that Encryption model We adopt the encryption model of [3] generate fresh keys; and the released-key environment R is and consider nondeterministic encryption schemes with ini- a set of released keys. tial vectors. As foreshadowed in Section 3, encryption schemes are represented as triples of the form (K, E, D), Semantics for expressions Similarly to the simple lan- where K is a key generation algorithm, E is an encryption guage in Section 2, the semantics for expressions have the algorithm, and D is a decryption algorithm. The encryption form hM, ei ⇓ v, where v is the result of evaluating expres- algorithm is a function of a key, a plaintext, and an initial sion e in memory M. vector (which we sometimes omit when its value is unim- Figure 5 presents the rules specific to the treatment of portant). For the same key and plaintext it returns different cryptography. Encryption (S-ENC) and decryption (S-DEC) ciphertexts depending on the value of the initial vector. Two both use the encryption schemes SEγ introduced above. ciphertexts are low-related if they have been encrypted with The rest of the rules can be found in the full version [5] the same initial vector iv: of the paper. . ∀k1, k2, v1, v2 . E(k1, v1, iv) = E(k2, v2, iv) Semantics for commands Similarly to Section 2, the se- This relation has the following properties: (i) different ci- mantics for commands have either the form hE, ci −→α phertexts produced by one plaintext and one key have dif- hE0, c0i, where E and E0 are the initial and resulting en- ferent initial vectors and are not low-related, and (ii) since vironments, c and c0 are the initial and resulting commands, every plaintext and key produce ciphertexts using all ini- and α ∈ {², `} is an event annotation (where ` is the projec- tial vectors, for each ciphertext produced by one plaintext tion E0 of the environment E0 = (M 0,G0,R0) defined as L and key there will be exactly one low-related ciphertext for 0 0 0 0 ↓ 0 EL = (ML,G (L),R )); or the form hE, ci −→ E , which every other choice of plaintext and key. indicates termination in the environment E0. The distinc- This construction prevents occlusion, which would hap- tive primitive of the language is a key release command pen if we treated all ciphertexts as equal, as illustrated in an release(k) that updates the set of released keys with the example that follows Proposition 4. value of the key k, in case the key is high. In Figure 6, we display the two most interesting rules for commands. Key Low-equivalence Let E ∼ E denote that the environ- generation (S-NEWKEY) takes a variable name and a level 1 Γ 2 ments E and E are low-equivalent with respect to the en- of the key to be generated and assigns the topmost element 1 2 vironment type Γ (i.e., their low projections are the same). in the key stream associated to that level in the key-stream The low-equivalence relation, presented in Figure 7, environment to the variable. The rule (S-KEY-RELEASE) for the key release primitive generates a release event and up- draws on one in [3]. In addition, it also reflects that once dates the set of released keys R in the environment. The rest a key has been released, it is unsafe to encrypt with this key of the rules can be found in the full version [5]. or, more precisely, assign the result of the encryption to a low variable. Low-equivalence is defined structurally with respect to 4 Gradual release for the enriched language the type of its arguments and the set of released keys rˆ. For example, two high keys are indistinguishable (i.e., related This section applies the gradual release approach to the by low-equivalence) if none of them has been released (rule language defined in Section 3. Although the language does (LE-KEY-SK)). On the other hand, only equivalent values of
6 hM, e1i ⇓ k hM, e2i ⇓ v k ∈ Keyγ u = Eγ (k, v) (S-ENC) hM, encryptγ (e1, e2)i ⇓ u
hM, e1i ⇓ k hM, e2i ⇓ u k ∈ Keyγ v = Dγ (k, u) (S-DEC) hM, decryptγ (e1, e2)i ⇓ v
Figure 5. Selected semantic rules for expressions
G(γ) = k · ks (S-NEWKEY) h(M, G, R), newkey(x, γ)i −→ (M[x 7→ k],G[γ 7→ ks],R) ( hM, ei ⇓ k k ∈ Keyγ {k} if γ = HK, (S-KEY-RELEASE) where S = r:(M ,G(L),S∪R) h(M, G, R), release(e)i L −→ (M, G, S ∪ R) ∅ otherwise
Figure 6. Selected semantic rules for commands low and released keys are indistinguishable (rules (LE-KEY- tial view of what keys may be known to the attacker. SK) and (LE-KEY-RK)). For example, the value of the key k2 in the expression The rules that define the low-equivalence of encrypted encryptHK (k1, (x, k2)) is not contained in the released-key values are worth highlighting. The rules (LE-ENC-L1) and environment after k1 is released. Nevertheless, using k2 for (LE-ENC-L2) both require ciphertexts to be low-related by encrypting high values after the release of k would be dis- . 1 the relation = on encrypted values. Their additional de- astrous since the attacker knows the exact value of k2 and, mands on the ciphertexts depend on whether the encryp- hence, can decrypt ciphertexts encrypted with it. Therefore, tion key is released and what its type is. The first rule (LE- the set of all released keys rˆ is computed, in a Dolev-Yao ENC-L1), when γ = RK, requires that low-equivalent cipher- style [14], by traversing low events and accumulating the texts obtained with released keys must agree on the value of keys that depend on the ones that are already released. We the key and plaintext (because anyone can decrypt them). use an accumulator function r(τ, v, R) defined inductively This is achieved by demanding that keys and plaintexts are on a variable type τ, a value of that type v, and an initial set low-equivalent with respect to the types tolow(key γ) and of released keys R: tolow(τ). The function tolow(·), defined in Figure 7, con- verts high primitive types into low ones. r(encγ τ L, u,R) = {r(tolow(τ), v, R) | Similarly to released keys, the demand for low keys (LE- ∃v, k . v = Dγ (k, u) ∧ (k ∈ R ∨ γ = LK)} ENC-L1, γ = LK) is that plaintexts are low-equivalent with r(encγ τ H, u, R) = ∅ r(int σ, v, R) = ∅ respect to the type tolow(τ). The only demand for encryp- r(key LK, k,R) = ∅ r(key HK, k,R) = ∅ tion with high keys (LE-ENC-L2) is that the resulting values r(key RK, k,R) = {k} should be low-equivalent with respect to the primitive type r((τ1, τ2), (v1, v2),R) = r(τ1, v1,R) ∪ r(τ2, v2,R) τ of the encryption type. Uninitialized values (denoted by •) are low-equivalent For a given typing environment Γ and a sequence ~` of (rule (LE-ENC-L3)). The rule (LE-ENC-H) relates high ci- low events (`1, . . . , `n), where `i = (Mi,Gi,Ri), we let: phertexts if one of them is uninitialized or their primi- r = R , and tive type structures are the same (an auxiliary predicate 0 Sn r = n {r(Γ(x),M (x), r ) | x ∈ dom (Γ)} struct(τ, v), which holds whenever v has type structure τ, j i=1 i j−1 is given in Figure 7). Note that an uninitialized value is low- The set rˆ is then defined as rk such that rk = rk+1. Such a equivalent to any other value. This is also reflected in the k exists because the set of keys that can be extracted from • rule (LE-MEM), where v is either a value or •. the sequence ~` of low events is finite. Two sequences of low events ~` and `~0 are low-equivalent Gradual release for the enriched language Before we if the numbers of events in each of the sequences are the proceed to gradual release for the enriched language, we same, the sets of all released keys that are computed from define low-equivalence on event sequences. each of them are equivalent, and the sequences agree on Note that the released-key environments, which are every respective element, i.e., memories, key generating explicitly recorded by low events, provide only a par- streams, and released-key environments are low-equivalent:
7 (LE-INT-L) (LE-INT-H) (LE-KEY-LK) rˆ rˆ rˆ n ∼ n n1 ∼ n2 lk ∼key LK lk int L int H rˆ rˆ hk ∈ rˆ v11 ∼τ v21 v12 ∼τ v22 (LE-KEY-RK) (LE-ENC-L3) (LE-PAIR) 1 2 rˆ rˆ rˆ hk ∼key RK hk • ∼ • (v , v ) ∼ (v , v ) encγ τ L 11 12 (τ1,τ2) 21 22 hk i 6∈ rˆ i = 1, 2 • • rˆ • (LE-KEY-SK) ∀x ∈ dom (Γ).Mi(x) = vi (i = 1, 2) =⇒ v1 ∼Γ(x) v2 rˆ (LE-MEM) hk 1 ∼key HK hk 2 rˆ M1 ∼Γ M2 rˆ rˆ rˆ rˆ k1 ∼key γ k2 K1 ∼γ K2 G1(HK) ∼HK G2(HK) G1(LK) ∼LK G2(LK) (LE-KGEN1) (LE-KGEN2) rˆ rˆ k1 · K1 ∼γ k2 · K2 G1 ∼ G2
∃j . uj = • ∨ ∃vi, ki . vi = Dγ (ki, ui) i = 1, 2 rˆ rˆ . struct(encγ τ H, ui)(i = 1, 2) k1 ∼key HK k2 v1 ∼τ v2 u1 = u2 (LE-ENC-H) (LE-ENC-L2) rˆ rˆ u1 ∼encγ τ H u2 u1 ∼encHK τ L u2 rˆ rˆ . ∃vi, ki . vi = Dγ (ki, ui) i = 1, 2 k1 ∼tolow(key γ) k2 v1 ∼tolow(τ) v2 u1 = u2 (LE-ENC-L1) rˆ u1 ∼encγ τ L u2
struct(int σ, n) struct(key γ, k)
tolow(t σ) = t L tolow(key LK) = key LK struct(τ1, v1) struct(τ2, v2) tolow(key HK) = key RK tolow(key RK) = key RK struct((τ1, τ2), (v1, v2)) tolow((τ1, τ2)) = (tolow(τ1), tolow(τ2)) ∃v, k . v = Dγ (k, u) struct(key γ, k) struct(τ, v)
struct(encγ τ σ, u)
Figure 7. Low-equivalence
A new ingredient—the low-equivalence of low-event se- quences ~` ∼ `~0—is used in the definition, which allows R = R0 rˆ(~` ) =r ˆ(~`0 ) =r ˆ Γ i i n n for relating ciphertexts that are obtained from different keys M ∼rˆ M 0 G ∼rˆ G0 i = 1 . . . n i Γ i i i and plaintexts. This prevents the knowledge from becom- ~ ~0 `n ∼Γ `n ing more precise. Otherwise, publishing a result of an en- Similarly to the simple language, we define the set of pos- cryption with a high key would narrow down the knowledge sible low-event sequences. We assume that initial environ- about the key and the plaintext behind the ciphertext to their ments (which we indicate with a superscript as in E0) have exact values, which is infeasible to infer for the attacker. the form (M, G, ∅), i.e., their released-key sets are empty. Accordingly, the definition of the initial knowledge is: In such an environment, we let M(x) = • for all such x that ~` 0 0 0 ~ ∗ 0 x : encγ τ σ, i.e., all variables of ciphertext type are unini- k(c, EL ) , {E | EL ∼Γ EL ∧ ∃E , ` . hE, ci −→ E } tialized. Given a command c and a projection of an initial 0 0 and the termination-insensitive knowledge is: environment EL , the set of possible low events L(c, EL ) is: 0 ~ 0 ~ 0 k↓(c, EL , `) , k(c, EL , `) ∩ k(c, EL ) ~` 0 ~ 0 0 ∗ 0 L(c, EL ) , {` | ∃E,E .EL ∼Γ EL ∧ hE, ci −→ E } The definition of gradual release for the enriched lan- The definition of knowledge is in order, also similar to the guage follows Definition 2 for the simple language: one for the simple language. Given the low projection of Definition 3 (Gradual release). A command c satisfies grad- 0 an initial environment EL and a (possibly empty) sequence ual release if for all low projections of initial environ- ~ b 0 b 0 0 0 of low events ` ∈ L(c, EL ), where L(c, EL ) denotes the ments EL such that R = ∅ and sequences of low events i 0 ~ ~ 0 ~ prefix closure of L(c, EL), the knowledge k(c, EL , `) of the ` ∈ L(c, EL ), where `n = (`1, . . . , `n), n ≥ 1, of which attacker is defined as: `r1 , . . . , `rm are all release events, we have: 0 ~ 0 0 0 ~0 k(c, EL , `) , {E | EL ∼Γ EL ∧ ∃E , c , ` . ∀i . 1 ≤ i ≤ n . (∀j . rj 6= i) =⇒ `~0 `~0 0 ~ 0 ~ ∗ 0 0 ∗ 0 ~ ~0 k↓(c, EL , `i−1) = k↓(c, EL , `i) (hE, ci −→ hE , c i ∨ hE, ci −→ E ) ∧ ` ∼Γ ` }
8 0 ~ 0 where k↓(c, EL , `0) , k(c, EL ). each event sequence generated by running the first config- We illustrate the definition by simple examples (more in- uration there is a low-equivalent event sequence generated teresting examples are deferred to Section 5). by running the second one (and vice versa by symmetry). The following program is accepted by gradual release: Proposition 4. If a command c is free of key release primi- k := newkey(HK); l := encryptHK(k, h); tives, then c satisfies gradual release if and only if c satisfies Different low-event sequences that can be produced by this possibilistic noninterference. program correspond to different values of the variable l. This proposition parallels Proposition 3. If there is no Since the encryption key is high, every value of l is low- key release, then the attacker’s knowledge must stay un- equivalent to ciphertexts produced by all other possible keys changed throughout execution. Therefore, this proposition and plaintexts. Therefore, for each possible sequence of low reduces to showing an analogue of Proposition 2, which is events that this program may generate, the knowledge con- straightforward. tains all possible keys and plaintexts, i.e., it is equal to the Consider the following code, which is inspired by an oc- initial knowledge and remains constant throughout all runs. clusion example from [3]. The program below is intuitively Gradual release rejects the following program: insecure: depending on the value of h the value of y is either k := newkey(HK); l := encryptHK(k, h); l’:= h; a new encryption, or the copy of x. An attacker observing that x and y are different can derive that the first branch has Similar to an example in Section 2, the last assignment nar- been taken. rows down the set of possible initial values for the variable h to exactly one. x := encryptHK(k1, h1); if h then y := encryptHK(k2, h2); On the other hand, gradual release accepts this program: else y := x; k := newkey(HK); l:=encryptHK(k, h); release (k); l’:= h; Thanks to the initial-vector mechanism (described in the There are four low events in this program: the encryption, beginning of the section), the program is rejected by both release statement, last assignment, and termination. As in gradual release and possibilistic noninterference. An initial the previous example, publishing the result of encryption memory M, where the value for h is 1, produces a sequence of low events where the final values v and v of x and y, does not change the knowledge. The release statement, . x y however, triggers a change in the low-equivalence for the respectively, are such that vx 6= vy. On the other hand, a 0 value of l: once the key k is released, it is only related with memory M , where the value of h is 0 is not a part of the 0 ciphertexts that agree with l both on the value of the key and knowledge. Indeed, under M , it is possible to produce a the plaintext. This corresponds to refining the knowledge to low-event sequence where v = vx and v is the final value of 0 both x and y under M 0, but then, since the second branch is the exact values of k and h. Thus, the last assignment to l . does not make the knowledge more precise. Gradual release taken, it implies v 6= vy. This means that we cannot reach accepts this program since the only point where the knowl- the final memory with the value vy for y from the mem- 0 0 edge changes is the release event. ory M , and, therefore, M is not a part of the knowledge. Because the knowledge is refined, and there are no release events to justify the refinement, the above program is re- Conservativity with respect to cryptographically- jected. masked flows As a sanity check, we demonstrate that Definition 3 is a conservative extension of possibilistic Relation to gradual release for the simple language As noninterference. another sanity check, we establish a relation to the definition Our possibilistic security definition is based on the one of of gradual release (Definition 2) for the simple language cryptographically-masked flows [3], although it represents (Section 2). The combination of the key generation, encryp- an attacker that observes event sequences rather than final tion/decryption, and key release features in the enriched environments. Assume T (c, E) is the set of possible event language turns out to be crucial for connecting encryption- sequences generated by a command c in an environment E. based declassification to revelation-based information re- A command c satisfies possibilistic noninterference if: lease. We can translate the general revelation-based declas- sification command in the following way: ∀E1,E2 .E1 ∼ E2 ∧ T (c, Ej) 6= ∅, j = 1, 2 =⇒ Γ l := declassify(e) ,→ ~ ~ ~ ~ ∀`1 ∈ T (c, E1) ∃`2 ∈ T (c, E2) . `1 ∼Γ `2 k := newkey(HK); t := encryptHK(k, e);
release(k); l := decryptRK(k, t); That is, for every pair of low-equivalent environments and for some fresh temporary variable t. Assuming that the configurations that terminate in these environments, and for transformation does not change other commands than de-
9 classifications, we arrive at the following formal connection tuples and encryption types, dependency relations track de- between the two definitions. pendencies between extended types. The typing rules for commands thus have the form A, Γ˜, pc ` c ⇒ A0, where A Proposition 5. A command c in the simple language satis- and A0 are the initial and final dependency relations. fies gradual release (Definition 2) if and only if command c0 0 To access the dependency relation, the typing rules em- obtained from c by transformation (c ,→ c ) in the enriched ploy an interface which we describe below. An accompa- language satisfies gradual release (Definition 3). nying technical report [5] describes a graph transformation- As an example, consider the following command in the based implementation that matches this interface. simple language: if h then l := declassify(h1); Analysis interface and requirements Let A denote a key else l := declassify(h2); dependency relation. The interface for accessing A is then l’ := h; defined by the following syntax: The transformation produces the following result in the en- riched language: type connectors conn ::= τ˜ 1 | τ˜1 → τ˜2 | κ % if h then k := newkey(HK); analysis transf. ::= upd (A, conn) t := encrypt (k, h1); HK analysis comb. ::= join (A1, A2) release (k); l := decryptRK(k, t); fresh type ::= fresh (A, τ) else may-type ::= type (A, τ˜) k := newkey(HK); May t := encryptHK(k, h2); must-type ::= typeMust (A, τ˜) release (k); l := decryptRK(k, t); l’ := h; Type connectors together with the operator upd (A, conn) are used for updating the dependency relation. The τ˜ 1 This command is semantically equivalent to the following: connector marks the extended type τ˜ as unrelated to any k := newkey (S); other type. The τ˜1 → τ˜2 connector indicates that if τ˜1 is if h then h’ := h1 else h’ := h2; t := encryptHK(k, h’); released then τ˜2 is released as well. The κ % connector release (k); specifies that the key name κ is released. l := decryptRK(k, t); l’:= h; Joining relations is done by the operator join (A1, A2) which combines the information from A and A . The op- In the context with no information about the values of the 1 2 erator fresh (A, τ) takes a dependency relation A and a variables of h and h , this program (as well as the source of 1 2 primitive type τ and returns an extended type τ˜ that has the the transformation) is rejected by the gradual release since same structure as τ, but the key names in it are fresh. This the last assignment leaks the exact value of the variable h operator may be used in the extended environment construc- that is unknown to the attacker otherwise. tion and in the typing rule for variable lookup. Obtaining the results of the analysis is done via the func- 5 Enforcement tions typeMay (A, τ˜) and typeMust (A, τ˜). These functions cast the extended type τ˜ to a primitive type taking into ac- This section presents a type and effect system that en- count all possible (resp. definite) key dependencies in A. forces gradual release for the enriched language. The type Given an environment E = (M, G, R), a dependency system uses an extended typing environment in which type relation A, and an extended typing environment Γ˜, we say annotations for keys are lifted to contain unique names that A enforces E, denoted by A, Γ˜ |= E, when for all key κ ∈ KeyNames: names that occur in Γ˜ the following holds:
ext. basic types t˜ ::= int | encκ τ˜ 1. If the analysis returns that a key name may not have ext. prim. types τ˜ ::= t˜ σ | key κ | (˜τ, τ˜) been released, then key values in the memory environ- ment associated with that name are not in the set of all Such an environment can be easily obtained by enumerating released keys all occurrences of key types in the variable environment Γ; the resulting extended environment is denoted as Γ˜. 2. If the analysis returns that a key name must have been The type system is also parameterized over a dependency released, then key values in the memory environment analysis that tracks possible and definite key dependencies associated with that name are in the set of all released in a program. A dependency relation is maintained through- keys. out the typing rules, which makes the type system aware of the key names that may or must have been released at Our demands on the analysis implementation can be ex- every program point. Since key names may appear inside pressed as follows:
10 0 Γ(˜ x) =τ ˜1 τ˜ : fresh (A, Γ(x)) (T-SKIP) 0 0 0 0 A, Γ˜, pc ` skip ⇒ A A = upd (A, τ~ 1, τ~ → τ~1, τ~1 → τ~ ) (T-VAR) ˜ ˜ 0 0 ˜ 0 0 Γ(x) =τ ˜ A, Γ ` e :τ ˜ , A A, Γ ` x :τ ˜ , A 0 0 pc v lvl(Γ(x)) typeMay (A , τ˜ ) <: Γ(x) A, Γ˜ ` e : key κ, A A , Γ˜ ` e :τ, ˜ A 0 0 1 1 1 2 2 typeMust (A , τ˜ ) <: Γ(x) 00 0 0 0 typeMay (A1, key κ) = key HK A = upd (A , τ~ 1, τ~ → τ~ , τ~ → τ~) (T-ASGN) A3 = upd (A2, key κ → τ~) ˜ 00 (T-ENC1) A, Γ, pc ` x := e ⇒ A ˜ A, Γ ` encryptHK (e1, e2): encκ τ˜ L, A3 0 0 000 A, Γ˜, pc ` c1 ⇒ A A , Γ˜, pc ` c2 ⇒ A (T-SEQ) ˜ ˜ 00 A, Γ ` e1 : key κ, A1 A1, Γ ` e2 :τ, ˜ A2 A, Γ˜, pc ` c1; c2 ⇒ A type (A , key κ) = key γ γ 6= HK May 1 A, Γ˜ ` e : int σ, A0 lvl(˜τ) = σ A3 = upd (A2, key κ → τ~) 0 ˜ 0 (T-ENC2) A , Γ, pc t σ ` ci ⇒ Ai i = 1, 2 ˜ (T-IF) A, Γ ` encryptγ (e1, e2): encκ τ˜ σ, A3 ˜ 0 0 A, Γ, pc ` if e then c1 else c2 ⇒ join (A1, A2) ˜ A, Γ ` e1 : key κ1, A1 join (A, A00), Γ˜ ` e : int σ, A0 ˜ 0 00 A1, Γ ` e2 : encκ2 τ˜ σ, A2 A , Γ˜, pc t σ ` c ⇒ A (T-WHILE) typeMust (A1, key κ1) = key γ 0 00 (T-DEC1) A, Γ˜, pc ` while e do c ⇒ join (A , A ) A, Γ˜ ` decrypt (e , e ) :τ ˜σ, A γ 1 2 2 Γ(x) = key γ γ 6= RK Γ(˜ x) =τ ˜ 0 A, Γ˜ ` e1 : key κ1, A1 A = upd (A, τ~ 1) pc v lvl(Γ(x)) (T-NEWKEY) ˜ 0 A1, Γ ` e2 : encκ2 τ˜ σ, A2 A, Γ˜, pc ` newkey(x, γ) ⇒ A type (A , key κ ) = key RK Must 1 1 A, Γ˜ ` e : key κ, A0 pc = L typeMust (A2, key κ2) = key RK 00 0 (T-DEC2) A = upd (A , κ %) A, Γ˜ ` decrypt (e , e ): tolow(˜τ)σ, A (T-RELEASE) RK 1 2 2 A, Γ˜, pc ` release(e) ⇒ A00
Figure 8. Selected type rules for expressions Figure 9. Type rules for commands
security level of its argument:
lvl(t σ) = σ lvl((τ1, τ2)) = lvl(τ1) t lvl(τ2) 0 A, Γ˜, pc ` c ⇒ A ∧ A, Γ˜ |= E ∧ lvl(key HK) = H lvl(key LK) = L lvl(key RK) = L ~` ∗ 0 0 0 hE, ci −→ E =⇒ A , Γ˜ |= E Both rules update the dependency relations with informa- tion that the release of the ciphertext is now dependent on the release of the encryption key. The rules for decryption require that the level of the key used for decryption matches Expression typing rules The rules for expressions have the key level of the encrypted value. The result of decryp- the form A, Γ˜ ` e : τ, A0, where A0 tracks dependencies tion is tainted by the security level of the encrypted value, created by the expression e. Figure 8 presents the rules where the taint function is defined as follows: for non-standard expressions, while the other rules can be found in [5]. σ0 0 σ σ σ (t σ) = t (σ t σ )(τ1, τ2) = (τ1 , τ2 ) The rule for variable lookup (T-VAR) looks up the type (key LK)L = key LK (key RK)L = key RK of the variable in the extended environment and creates a (key HK)σ = key HK fresh type in the dependency relation that is connected to the original variable. The two rules for encryption corre- The interesting case, which uses the must analysis, is the spond to encryption with high non-released keys, and to rule (T-DEC2) that relaxes the returning value if both en- encryption with keys that have low or released levels. In cryption and decryption keys are known to be released. the first case, the rule (T-ENC1) allows the resulting type of the expression to have the low type L, if it is known that Command typing rules Figure 9 presents the command the key name used for encryption is definitely not released. type rules. The rules for a command c have the form The second rule (T-ENC2) preserves the original level of A, Γ˜, pc ` c ⇒ A0 where A and A0 are the dependency the plaintext σ; it uses the function lvl(·) that returns the relations before and after executing c.
11 6 Examples
This section provides examples of secure programming in the context of media distribution, mental poker, and bit commitment.
Media distribution In this example we consider the sce- Figure 10. Enforcement for high keys nario of media distribution. Large media is distributed in encrypted form prior to the official release date. On the date of release, secret keys are supplied to the consumers. The rule for assignment (T-ASGN) looks up the type of This protocol can be implemented in our language as fol- the variable in both normal and extended environments. It lows: evaluates the type of the expression to assign in the extended 1 // local var declarations environment and its may and must types, as recorded in the 2 key HK k; 3 int H media; dependency relation. We require both of these types to be 4 enc HK (int H) L outMedia; a subtype of the variable type. Next, we update the depen- 5 key RK outK; 6 dency relation with the new dependency between extended 7 // generating new key types. As is standard, the rule also checks that the pc label 8 k := newkey (HK); 9 media := ...; is bounded by the security level of the assigned variable. 10 // publishing the low value of the media 11 outMedia := encryptHK(k,media); The rule (T-SEQ) propagates the updated dependencies 12 ... through sequential composition. The rule for condition- 13 release(k); // releasing the key als (T-IF) evaluates the security level of the guard to check 14 outK := k; both branches; the resulting dependency relation is obtained The media is distributed via variable outMedia, whose type by joining the resulting relations for c1 and c2. In a similar enc HK (int H) L says that it stores low data which results flavor, the rule (T-WHILE) demands that there exists a pair from encrypting high data with high keys. At the media of dependency relations A0 and A00 such that we can type release time, the high key is released and published in the 0 the loop body in an environment starting from A and pro- variable outK, whose type says that it stores released keys. ducing A00. In addition, A0 is a result of evaluating loop This program is typable by the type system from Section 5 guard in an environment obtained by joining A and A00. and, thus, is secure. The rule (T-NEWKEY) for new key generation checks Note that premature key release is prevented by the type that the pc label is no greater than the level of the key to system. For example, if the lines generate. It looks up the extended type of the key variable in release(k); the extended environment and removes dependencies of this outMedia := encryptHK(k,media); type in the dependency relation. The rule (T-RELEASE) is are moved ahead of the encryption, then the program will the one where key names are marked as released. It also be rejected as insecure. enforces that release only happens in low context (under low pc). Mental poker A pattern similar to media distribution is Figure 10 demonstrates the key-related part of enforce- used in mental poker [35, 9, 4] protocols. Encryptions dur- ment of the type system for high keys. The type system ing the game correspond to card shuffling without trusted tracks the state in a simple automaton for each key name third party. At the end of the game, there is a verification and rejects the program if its (statically approximated) exe- phase to verify that no player was cheating. As with the cution paths might lead to a transition that is not prescribed fragment above, the type system guarantees that keys may by the automaton. not be released before the game phase is over.
Bit commitment using symmetric cryptography Bit commitment is a common building block in security proto- Soundness We denote by A0 dependency relations that cols. We are primarily concerned with the confidentiality of contain no released-key names. The type system provably the committed bit for our purposes. In a typical run between enforces gradual release for the enriched language: two principals, one of the principals commits its bid by en- crypting a tuple consisting of the bid and a random value Theorem 2. If A0, Γ˜, pc ` c ⇒ A0 then c satisfies gradual obtained from the other principal. The tuple is encrypted release. using a fresh key, which is later released in the revelation
12 phase. The following listing shows an example implemen- ducibility [36] Similarly to these approaches, we do not tation of the protocol for the committing principal. consider user strategies [40, 30] that can infer additional 1 // local var declarations knowledge. 2 int L rnd; Our starting point in modeling information flow in 3 key HK k; 4 enc HK
13 tinguishing feature of this work is the possibility of compu- on declared channels. While we can build on the message- tational characterization of data declassification. While our passing enabled language [3] for which cryptographically- goal (of having a practically enforceable security condition masked flows were introduced, we cannot directly reuse its at the programming-language level) is initially different, we security model because it considers actors in isolation. In share the ultimate goal of considering computational adver- presence of key release, it is not sufficient to view the actors saries with [6] (see the future work). independently because a key release by one actor may affect other actors. Thus, a goal for future work in this direction is 8 Conclusion to reason about whole-system security. In general, this in- volves reasoning about information flows due to blocking, scheduling, races, and other flows that may arise in concur- We have presented gradual release, a framework for uni- rent systems (cf. [32]). fying declassification, encryption, and key release policies. Although not in the scope of this paper, a high-priority direction for work on cryptographically-masked flows (with Contributions The benefits of the framework include the and without key release) is showing that semantic security following: under chosen plaintext attack (SEM-CPA) [17] (i.e., what- ever is efficiently computable about the cleartext given the • Policy-perimeter defense The framework is the first to ciphertext, is also efficiently computable without the ci- provide assurance for policies that include all of de- phertext) with an appropriate message authentication code classification, encryption, and key release; (e.g., INT-PTXT [7]) for the underlying cryptographic prim- itives is sufficient for the semantic security of programs • Connection between revelation-based and encryption- (with ample restrictions on key cycles) that satisfy the con- based declassification Not only does the framework dition of cryptographically-masked flows. combine revelation-based and encryption-based poli- cies, but also formally connects the two kinds of de- Acknowledgments classification: gradual release for revelation-based de- classification can be represented by a reassuringly sim- We wish to thank Daniel Hedin and David Sands for ple encryption-based declassification: declassifying an helpful discussions on an earlier draft of this paper. This expression corresponds to encrypting the expression work was funded in part by the Sixth Framework pro- with a fresh key and immediately releasing the key. In gramme of the European Community under the MOBIUS this light, the framework is the first to unify revelation- project FP6-015905, in part by VINNOVA, and in part by based and encryption-based declassification policies. the Swedish Research Council. • Conservativity We have shown that gradual release for programs with no declassification or encryption is References equivalent to a form of noninterference; in addition, we have shown that gradual release with no key re- [1] M. Abadi. Secrecy by typing in security protocols. J. ACM, lease (but possibly with encryption) is equivalent to a 46(5):749–786, Sept. 1999. form of possibilistic noninterference; and [2] A. Almeida Matos and G. Boudol. On declassification and the non-disclosure policy. In Proc. IEEE Computer Security • Type-based enforcement We have demonstrated that Foundations Workshop, pages 226–240, June 2005. gradual release can be enforced by type and effect sys- [3] A. Askarov, D. Hedin, and A. Sabelfeld. Cryptographically- tems. masked flows. In Proc. Symp. on Static Analysis, LNCS, pages 353–369. Springer-Verlag, Aug. 2006. [4] A. Askarov and A. Sabelfeld. Security-typed languages for Future work While gradual release emphasizes the implementation of cryptographic protocols: A case study. In where dimension of information release it only offers a rel- Proc. European Symp. on Research in Computer Security, ative (to the previous point of release) assurance as to what volume 3679 of LNCS, pages 197–221. Springer-Verlag, data is released. As sketched in Section 2, it is possible to Sept. 2005. fully integrate the what dimension by connecting each re- [5] A. Askarov and A. Sabelfeld. Gradual release: Unifying de- classification, encryption and key release policies. Technical lease point to a policy that regulates what can be leaked. report, Chalmers University of Technology, 2007. Located The benefit of cryptographic and key-release primitives at http://www.cs.chalmers.se/∼aaskarov/sp07full.pdf. is truly realized in a distributed setting. A natural extension [6] M. Backes and B. Pfitzmann. Intransitive non-interference of our language is one with actors that run concurrently and for cryptographic purposes. In Proc. IEEE Symp. on Security interact with each other by sending and receiving messages and Privacy, pages 140–153, May 2003.
14 [7] M. Bellare and C. Namprempre. Authenticated encryption: [24] P. Lincoln, J. C. Mitchell, M. Mitchell, and A. Scedrov. A Relations among notions and analysis of the generic com- probabilistic poly-time framework for protocol analysis. In position paradigm. In Advances in Cryptology - Asiacrypt ACM Conference on Computer and Communications Secu- 2000, volume 1976 of LNCS, pages 531–545, Jan. 2000. rity, pages 112–121, Nov. 1998. [8] N. Broberg and D. Sands. Flow locks: Towards a core cal- [25] H. Mantel. Possibilistic definitions of security – An assem- culus for dynamic flow policies. In Proc. European Symp. bly kit –. In Proc. IEEE Computer Security Foundations on Programming, volume 3924 of LNCS, pages 180–196. Workshop, pages 185–199, July 2000. Springer-Verlag, 2006. [26] H. Mantel and A. Reinhard. Controlling the what and where [9] J. Castellà-Roca, J. Domingo-Ferrer, A. Riera, and J. Bor- of declassification in language-based security. In Proc. Eu- rell. Practical mental poker without a TTP based on homo- ropean Symp. on Programming, LNCS. Springer-Verlag, morphic encryption. In Progress in Cryptology-Indocrypt, 2007. volume 2904 of LNCS, pages 280–294. Springer-Verlag, [27] H. Mantel and D. Sands. Controlled downgrading based on Dec. 2003. intransitive (non)interference. In Proc. Asian Symp. on Pro- [10] S. Chong and A. C. Myers. Security policies for downgrad- gramming Languages and Systems, volume 3302 of LNCS, ing. In ACM Conference on Computer and Communications pages 129–145. Springer-Verlag, Nov. 2004. Security, pages 198–209, Oct. 2004. [28] J. C. Mitchell. Probabilistic polynomial-time process cal- culus and security protocol analysis. In Proc. European [11] T. Chothia, D. Duggan, and J. Vitek. Type-based distributed Symp. on Programming, volume 2028 of LNCS, pages 23– access control. In Proc. IEEE Computer Security Founda- 29. Springer-Verlag, Apr. 2001. tions Workshop, pages 170–186, 2003. [29] A. C. Myers, A. Sabelfeld, and S. Zdancewic. Enforcing [12] D. E. Denning and P. J. Denning. Certification of programs robust declassification and qualified robustness. J. Computer for secure information flow. Comm. of the ACM, 20(7):504– Security, 14(2):157–196, May 2006. 513, July 1977. [30] K. O’Neill, M. Clarkson, and S. Chong. Information-flow [13] C. Dima, C. Enea, and R. Gramatovici. Nondeterministic security for interactive programs. In Proc. IEEE Computer nointerference and deducible information flow. Technical Security Foundations Workshop, pages 190–201, July 2006. Report 2006-01, University of Paris 12, LACL, 2006. [31] J. M. Rushby. Noninterference, transitivity, and channel- [14] D. Dolev and A. Yao. On the security of public-key proto- control security policies. Technical Report CSL-92-02, SRI cols. IEEE Transactions on Information Theory, 2(29):198– International, 1992. 208, Aug. 1983. [32] A. Sabelfeld and A. C. Myers. Language-based information- [15] D. Duggan. Cryptographic types. In Proc. IEEE Computer flow security. IEEE J. Selected Areas in Communications, Security Foundations Workshop, pages 238–252, June 2002. 21(1):5–19, Jan. 2003. [16] J. A. Goguen and J. Meseguer. Security policies and security [33] A. Sabelfeld and A. C. Myers. A model for delimited in- models. In Proc. IEEE Symp. on Security and Privacy, pages formation release. In Proc. International Symp. on Software 11–20, Apr. 1982. Security (ISSS’03), volume 3233 of LNCS, pages 174–191. [17] S. Goldwasser and S. Micali. Probabilistic encryption. Jour- Springer-Verlag, Oct. 2004. nal of Computer and System Sciences, 28:270–299, 1984. [34] A. Sabelfeld and D. Sands. Declassification: Dimensions [18] A. Gordon and A. Jeffrey. Secrecy despite compromise: and principles. J. Computer Security, 2007. To appear. Types, cryptography, and the pi-calculus. In Proc. CON- [35] A. Shamir, R. Rivest, and L. Adleman. Mental poker. Math- CUR’05, number 3653 in LNCS, pages 186–201. Springer- ematical Gardner, pages 37–43, 1981. Verlag, Aug. 2005. [36] D. Sutherland. A model of information. In Proc. National [19] J. Halpern and K. O’Neill. Secrecy in multi-agent systems. Computer Security Conference, pages 175–183, Sept. 1986. In Proc. IEEE Computer Security Foundations Workshop, [37] D. Volpano. Secure introduction of one-way functions. pages 32–46, June 2002. In Proc. IEEE Computer Security Foundations Workshop, [20] B. Hicks, D. King, P. McDaniel, and M. Hicks. Trusted pages 246–254, July 2000. [38] D. Volpano and G. Smith. Verifying secrets and relative se- declassification: High-level policy for a security-typed lan- crecy. In Proc. ACM Symp. on Principles of Programming guage. In Proc. ACM SIGPLAN Workshop on Programming Languages, pages 268–276, Jan. 2000. Languages and Analysis for Security, June 2006. [39] D. Volpano, G. Smith, and C. Irvine. A sound type system [21] P. Laud. Semantics and program analysis of computationally for secure flow analysis. J. Computer Security, 4(3):167– secure information flow. In Proc. European Symp. on Pro- 187, 1996. gramming, volume 2028 of LNCS, pages 77–91. Springer- [40] J. T. Wittbold and D. M. Johnson. Information flow in non- Verlag, Apr. 2001. deterministic systems. In Proc. IEEE Symp. on Security and [22] P. Laud. Handling encryption in an analysis for secure in- Privacy, pages 144–161, 1990. formation flow. In Proc. European Symp. on Programming, [41] A. Zakinthinos and E. S. Lee. A general theory of security volume 2618 of LNCS, pages 159–173. Springer-Verlag, properties. In Proc. IEEE Symp. on Security and Privacy, Apr. 2003. pages 94–102, May 1997. [23] P. Laud and V. Vene. A type system for computationally [42] S. Zdancewic. Challenges for information-flow security. In secure information flow. In Proc. Fundamentals of Compu- Proc. Programming Language Interference and Dependence tation Theory, volume 3623 of LNCS, pages 365–377, Aug. (PLID), Aug. 2004. 2005.
15