CIS 6614 meeting -*- Outline -*- * Information Flow Security ** What is the problem? *** recap, Denning and Denning (1977) Recall from earlier... ------------------------------------------ INFORMATION FLOW SECURITY Original paper: Dorothy E. Denning and Peter J. Denning. "Certification of programs for secure information flow." CACM 20(7):504-513, July 1977. https://doi.org/10.1145/359636.359712 Confinement problem: - "confidential results should not depend on non-confidential data" Policy specified by: Example: int Y = 0; if (X == 0) { Y = 0; } else { Y = 1; } ------------------------------------------ ------------------------------------------ RULES FOR INFORMATION FLOW ANALYSIS Taint checking plus: - implicit flows: from objects used in a condition to objects changed by code run conditionally ------------------------------------------ ** programming languages perspective (Sabelfeld and Myers, 2003) ------------------------------------------ ANOTHER LOOK AT THE PROBLEM See: A. Sabelfeld and A. C. Myers, Language-based information-flow security. IEEE Journal on Selected Areas in Communications, vol. 21(1):5-19, Jan. 2003 doi: 10.1109/JSAC.2002.806121 Standard for protecting confidential data: - access control Does that keep data confidential? Possible problems: ------------------------------------------ Q: What does access control say about access to confidential data (e.g., a file)? You need authorized access (permission) ... not necessarily depends on how the infomation is used after access Example: agent has access to top secret information, reads it, then gives it to enemy... Q: Does encryption solve these problems? No, still use after reading is not controlled Possible problems: ... - errors, bugs - malice ------------------------------------------ MOTIVATION (from Sabelfeld and Myers, 2003) To ensure that info remains confidential: must analyze how information flows within program using it. Further: modern computing systems are complex, so manual analysis is infeasible Goal: Show information does NOT flow to where policy could be violated. ------------------------------------------ This is a paraphrase of the first page (right column) ** security-typed programming language recall that type checking is a kind of static program analysis... ------------------------------------------ APPROACH: SECURITY TYPING Idea: - annotate types with policy specifications on use of data - enforce policies statically Advantages: ------------------------------------------ Q: When does static enforcement happen? At compile time! Q: What is the runtime overhead of static enforcement? Very small, if any (only resulting from crippled langauge capabilities, say vs. C, that are needed to make the analysis sound) ... - little or no overhead at runtime - compositional (modular) secure subsystems can be composed into secure systems - formal guarantees ** challenges ------------------------------------------ CHANNELS Def: a *channel* is a mechanism for Def: a *covert channel* is a channel that Examples: ------------------------------------------ ... transmitting information ... was not intended for communication ... - implicit flows: using control flow of a program - timing: how long a program takes to execute - power: how much power (electricity) a program uses (also: termination, probability distribution of output, and resource exhaustion) Q: What does existence of covert channels tell us about security research? That the set of assumptions made (the attack model) is important, and needs to be based in reality of actual system ------------------------------------------ INTEGRITY: DUAL OF CONFIDENTIALITY Confidentiality stops information flows TO improper SINKS Def: *integrity* stops information flows FROM improper SOURCES ------------------------------------------ Q: In the military, what role does integrity play? Prevents misinformation from the enemy from influencing decisions ** Example of Implicit Flows ------------------------------------------ EXAMPLE OF IMPLICIT FLOWS (from Fig. 1 of Sabelfeld and Myers, 2003) secret int h; /* high security */ public int l; /* low security */ /* ... */ h = h % 2; l = 0; if (h == 1) { l = 1; } Problem with Mandatory Access Control: - rest of program must be secret level! called "label creep" ------------------------------------------ Q: How does the value of l relate to the value of h at the end? They are the same! Q: Is this demonstrating an explicit or implict flow? implicit ** type checking for information flow ------------------------------------------ TYPE CHECKING INFORMATION FLOW security types: - normal type (e.g., int), - security label type checks - usual type checks and - check that flow permitted For implicit flows: - label program counter (pc) - track dependencies on conditions but only within scope of condition ------------------------------------------ Q: Does this prevent label creep? Yes! *** goal: noninterfereence this is what we want to prove ------------------------------------------ GOAL: NONINTERFERENCE Def: The *noninterference policy* says that Test: ------------------------------------------ ... confidential data may not influence public data ... run program twice with different secret values results of public data must be same *** type system **** programming language as is typical, we formalize using a "toy" programming language ------------------------------------------ PROGRAMMING LANGUAGE FOR PROOFS Syntax: C ::= skip | var := exp | C1 ; C2 | if exp then C1 else C2 | while exp do C exp ::= var | constant | exp op exp var ::= h | l Semantics: v in Value = {..., -2, -1, 0, 1, 2, ...} s in State = {(sh, sl) | sh: var -fin-> Value and sl: var -fin-> Value } M: C -> (State -> (State union {\bot})) ------------------------------------------ C is commands exp is expressions var is variable names Might have values other than Integers, but this is simple (var -fin-> Value) is the set of all finite maps from var to Value M is the "meaning" function for commands \bot means "nontermination" Q: When M is applied to a command C and a state s, what can the result be? either a new state or \bot (nontermination) **** formal statement of noninterference ------------------------------------------ FORMAL STATEMENT OF NONINTERFERENCE Equivalence relation on states: Def: (sh,sl) ==L (sh',sl') iff sl == sl' Def: A command C has the *noninterference property* iff forall s1, s2 in State s1 ==L s2 implies (M(C)(s1)) ==L (M(C)(s2)) ------------------------------------------ Q: What does that formula mean? Whenever two states have the same low part, then the effect of C on them is to produce states with the same low parts Q: What does that mean for confidentiality? Any differences in the high parts does not affect C's meaning on the low parts Q: in ==L, why are is the high part of the state ignored? because we want to know if the low parts are unchanged. ------------------------------------------ EXAMPLES Which has the noninterference property? h := l+4 l := h if (l == 5) then h:=h+1 else l:=l+1 if (h == 3) then l:=5 else skip ------------------------------------------ ... the first and third are non-interfering **** type system ------------------------------------------ TYPING JUDGMENTS |- exp : t means exp has type t [pc] |- C means C type checks in context [pc] ------------------------------------------ This is defining some notation which is used to give proof rules Really we can prove that exp has type t in the empty context and that in the security context [pc] C is provably okay ------------------------------------------ TYPE RULE NOTATION hyp1, hyp2 [name] ----------- concl means axiom schemes: [low] |- l : public Side conditions: e |- x : t, e |- y : t2 [lookup] ----------------------- e |- x : t3 if e(x)=t, e(y)=t2, and t3 = t+t2 Free variables are universally quantified over ENTIRE rule: |- h : secret, l : public [plus] --------------------------- h+l : secret |- exp1 <= exp2, |- exp2 <= exp3 [trans] ----------------------------- |- exp1 <= exp3 ------------------------------------------ ... if hyp1 and hyp2 can be proven, then concl follows alternatively: to prove concl, it suffices to prove hyp1 and hyp2 (This is sometimes called a "natural deduction system") Q: Can we take h to mean one thing in the hypothesis and another in the conclusion? No, the violates the convention Axioms have no hypotheses, often have horizontal line omitted Side conditions are supposed to be Boolean-valued conditions that determine if a rule can be applied In theory, all non-judgement computation goes into side conditions, but in practice people write these as hypotheses Q: What does the trans rule mean? Note that it's not a judgment in our system but it means that to prove exp1 <= exp3 it suffices to find some exp2 such that exp1 <= exp2 and exp2 <= exp3 ------------------------------------------ TYPE RULES See: (Sabelfeld and Myers, 2003) and D. Volpano, G. Smith, and C. Irvine. A sound type system for secure flow analysis. J. Comput. Security, vol. 4(3):167--187, 1996. assume h is the secret (high) variable l is the public (low) variable [TE1] |- exp : secret [TE2] |- exp : public if h not in Vars(exp) [TC1] [pc] |- skip [TC2] [pc] |- h := exp |- exp: public [TC3] -------------------- [public] |- l := exp [pc] |- C1, [pc] |- C2 [TC4] ---------------------- [pc] |- C1 ; C2 |- exp : pc, [pc] |- C [TC5] ----------------------- [pc] |- while exp do C |- exp : pc, [pc] |- C1, [pc] |- C2 [TC6] ----------------------------- [pc] |- if exp then C1 else C2 [secret] |- C [TC7] ------------------- [public] |- C ------------------------------------------ To avoid the assumption about names like h, could use a security environment, e, a map from names to security labels e.g., e(h) = secret e(l) = public this would then be part of the context (for both expressions and commands) Q: What bad outcome are we trying to avoid? leaking secret information by allowing an assignment from h to l (l := h) Q: What does TE1 mean? Can always type check an expression as secret Why is that okay, because it is more restrictive (imprecision here is safe) Q: When can TE2 be used? When the secret variable (h) is NOT found in exp Q: Why is TC1 sound? because skip makes no assignments Q: Why is TC2 sound? because can always assign to h (avoids bad outcome) Q: How does TC3 prevent explicit flows? it requires the expression to be public Q: Why is the security context for TC3 [public]? so that there is no implicit flow Q: What is TC4 saying? That you type check a sequential composition by type checking each statement separately Why can't [pc] change by C1? Statements never change the surrounding context Q: Where does [pc] come from in TC5 and TC6? Why? from the security type of exp (the condition) To prevent implicit flows from allowing bad outcomes Q: What is TC7 saying? Why is it sound? That you can always make the security context more restrictive, i.e., to prove C is okay in a public context, you could prove it's okay in a secret context This is a kind of "subsumption" rule Note that aside from TE1 and TC7, the conclusions of the rules are the same as the grammar; this is needed so that the (inductive) definition of type checking is completely defined (well-defined) Heuristic: always check that every grammar rule appears in some conclusion (can be in more than one, like exp, if there are side conditions, then need to check that the side conditions cover all possible cases) ------------------------------------------ EXAMPLE OF TYPE CHECKING --------------------------------- [public] |-if h == 1 then l := 1 else skip ------------------------------------------ Note, need to use TC6 due to form of conclusion Show how get the three hypotheses: ... [TE1] |- h ==1 : secret, [ ] [secret] |- l := 1, [TC1] [secret] |- skip but no proof for the second hypothesis! so this fails!