Containment and Integrity for Mobile Code Security policies as types Andrew Myers Fred Schneider Department of Computer Science Cornell University

13 Feb 01Security policies as types — Andrew Myers 2 Projects Security policies as types –support for low-level languages –reacting to intrusion: untrusted hosts Composing fault-tolerance and security –Asynchronous, proactive secret sharing –COCA online certification authority Inlined reference monitors

13 Feb 01Security policies as types — Andrew Myers 3 Protecting data against programs Goal: confidentiality, integrity of information How to enforce as system-wide property? –There are almost no trusted programs Information flow policies: end-to-end principle applied to security “the system cannot allow information to flow from source A to destination B”

13 Feb 01Security policies as types — Andrew Myers 4 Security-typed languages Idea: encode security policies in type system –Programs not allowed to run unless type-correct Advantages: –Decidable enforcement –Low run-time overhead –Small TCB (?) –Compositional security Issues: –What security policies can be encoded as types? –Application to low-level code? –Distributed computation – who decides what to run?

13 Feb 01Security policies as types — Andrew Myers 5 Non-interference Information flow policies based on some form of non-interference “High” inputs cannot affect “low” observables Can be enforced by security type system H1L1 L2H2 H3L1 L2H4 LL

13 Feb 01Security policies as types — Andrew Myers 6 Issues Low-level code –Want to verify security in executable code –Useful for mobile code –Security type systems too restrictive TCB: host –Untrusted hosts –Intrusion –Dynamic coalitions Downgrading –Non-interference is too restrictive –What can be enforced if it is violated?

13 Feb 01Security policies as types — Andrew Myers 7 Security types A simple security type system: –Security type  =  H or  L where  an ordinary type –int H : a secret integer –int L : a public integer –More expressive labeling schemes exist Examples of use: int L x = e; // OK if e has type int L int H x = e; // OK if e has type int H or int L int H b; int L x = 0; if (b) { x = 1; } // not OK

13 Feb 01Security policies as types — Andrew Myers 8 Implicit flow in high-level lang. int H b; int L x = 0; if (b) { x = 1; /* not OK */ } Implicit flow: information carried through control structure Solution: introduce static approximation to implicit flow (pc) –Type of expression always acquires pc int H b; int L x = 0 L ; i f (b) { x = 1 H ; } pc updated by rules for type-checking control structures

13 Feb 01Security policies as types — Andrew Myers 9 Implicit flow in low-level lang. High-level control structures (if, while, switch, function calls, returns)  indirect, direct jumps Less ability to reason about implicit flow Simple rule: pc at target of jump always more secret than at jump instruction –captures possible implicit flow –too restrictive –doesn’t handle indirect jumps

13 Feb 01Security policies as types — Andrew Myers 10 Loss of precision int H b; /* pc = L */ int L x = 0 L ; /* pc = L */ if (b) { x = 1 H ; /* pc = H */} /* pc = L */ MOV x, 0; pc = L CMP b, 0; pc = L JZ skip; pc = H MOV x, 1; pc = H skip:; pc = H High-level: safe Low-level: apparently unsafe

13 Feb 01Security policies as types — Andrew Myers 11 A security-typed calculus First low-level typed language with support for dynamic control transfers, static information flow control [ESOP’01] Continuations in A-normal form: close to assembly code Linear continuations preserve precision of high-level source analysis First proof of language-based enforcement of non-interference (for any higher-order imperative language) e ::= let x = prim in e | let x = ref l  v in e | letlin y = lv in e | set v 1 := v 2 in e | if v then e 1 else e 2 | goto v 1 (v 2, lv) | lgoto lv 1 (v, lv 2 ) | halt  v

13 Feb 01Security policies as types — Andrew Myers 12 TCB: host Model so far: host/execution platform type- checks incoming code to enforce security properties On a system of many hosts? – no perimeter! Response to intrusion? Dynamic trust relationships?

13 Feb 01Security policies as types — Andrew Myers 13 Secure program partitioning Programs contain no explicit code locations or communication Automatically transformed (“split”) to run securely on current hosts Intrusion: re-split! Change in trust relationships: re-split! Implemented in Jif compiler [TR] source compiler intermediate code Host 1 splitter Host 2Host 3 code partition authenticated trust declarations

13 Feb 01Security policies as types — Andrew Myers 14 Downgrading/Declassification Information-flow security properties are too strong—real systems need to leak information Example: password-checking procedure leaks information about passwords even on failure Non-interference is all-or-nothing Robust vs. non-robust declassification: –Robust: declassification releases only the intended information –Non-robust: attackers can exploit declassification to release additional information A non-robust system: password checker if attacker can change passwords

13 Feb 01Security policies as types — Andrew Myers 15 Robust declassification Assumption 1: attacker can observe some aspects of system state  Assumption 2: attacker can cause changes to some aspects of system state  Observation: projection function  :  O System is robust with respect to attacker if attacker learns no more from attacked system than from simple observation       Non-interfering = ? = ? Robust A

13 Feb 01Security policies as types — Andrew Myers 16 Results Theorem: non-interfering systems are robust Theorem: all systems are robust against attackers whose power to modify (  A  ) is appropriately bounded –Integrity property derived automatically from confidentiality property First formal characterization of confidentiality+downgrading+active attacker; applicable to language-based enforcement

13 Feb 01Security policies as types — Andrew Myers 17 Policies Strong, information flow policies Simple access control policies Mutually distrusting but collaborating principals Dynamically changing trust relationships

13 Feb 01Security policies as types — Andrew Myers 18 Attacks Considered: –buggy or malicious downloaded code –storage channels, implicit flows –intrusion/integrity violation in multiple-host system –exploitation of downgrading channels Not considered: –denial of service –traffic analysis –timing, termination channels

13 Feb 01Security policies as types — Andrew Myers 19 Conclusions Information flow policies enforce system- wide security Progress: –Provably correct type-based enforcement for low- level code –Support for untrusted hosts, dynamically changing trust relationships—secure program partitioning –New theory of robust declassification