1. Language-Based Security Proof-Carrying Code Greg Morrisett Cornell University Thanks to G.Necula & P.Lee

2. June 2001Lang. Based Security2 Papers for this Lecture G. Necula, “Proof-Carrying Code”. PoPL'97. G.Necula and P.Lee. “Safe Kernel Extensions Without Run-Time Checking”. OSDI'96. G.Necula and P.Lee. “The Design and Implementation of a Certifying Compiler.” PLDI’98, June 1998. [pldi98.ps] I also highly recommend Necula’s PhD thesis (CMU).

3. June 2001Lang. Based Security3 Ideally: Your favorite language Low-Level IL optimizer machine code verifier Security Policy System Binary trusted computing base

4. June 2001Lang. Based Security4 Idea #1: Theorem Prover! Your favorite language Low-Level IL optimizer machine code NuPRLSecurity Policy System Binary trusted computing base

5. June 2001Lang. Based Security5 Unfortunately... NuPRL trusted computing base

6. June 2001Lang. Based Security6 Observation Finding a proof is hard, but verifying a proof is easy.

7. June 2001Lang. Based Security7 PCC: optimizer machine code verifierSecurity Policy System Binary prover codeproof could be you trusted computing base “certified binary” in- variants

8. June 2001Lang. Based Security8 Making “Proof” Rigorous: Specify machine-code semantics and security policy using axiomatic semantics. {Pre} ld r2,r1(i) {Post} Given: –security policy (i.e., axiomatic semantics and associated logic for assertions) –untrusted code –annotated with invariant assertions it’s possible to calculate a verification condition: –an assertion A such that –if A is true then the code respects the policy.

9. June 2001Lang. Based Security9 The Client The client takes its code & the policy: –constructs some loop invariants. –constructs the verification condition A from the code, policy, and loop invariants. –constructs a proof that A is true. codeproof “certified binary” in- variants

10. June 2001Lang. Based Security10 Verification The Verifier (~ 4-6 pages of C code): –takes code, loop invariants, and policy –calculates the verification condition A. –checks that the proof is a valid proof of A: fails if some step doesn’t follow from an axiom or inference rule fails if the proof is valid, but not a proof of A codeproof “certified binary” in- variants

11. June 2001Lang. Based Security11 Advantages of PCC In Principle:  Simple, small, and fast TCB.  No external authentication or cryptography.  No additional run-time checks.  “Tamper-proof”.  Precise and expressive specification of code safety policies. codeproof in- variants

12. June 2001Lang. Based Security12 An Experiment: Packet Filters Safety Policy: –given a packet, returns yes/no –packet is read-only, small scratchpad –no loops Compare: –Berkeley Packet Filter Interpreter –Modula-3 (but turn off type-checking) –Software Fault Isolation (sandboxing) –PCC (hand-optimized, proved)

13. June 2001Lang. Based Security13 Results: PCC wins:

14. June 2001Lang. Based Security14 Is PCC the answer? PCC seems to offer everything we need: –small, simple trusted computing base –optimize all you want, any language, any security policy, etc. But how do we make it scale to real programs?

15. June 2001Lang. Based Security15 Scaling Problem #1: How to generate proofs? Manual construction is too painful for real programs. Interactive theorem provers are really only feasible for a relatively small fraction of the code. We need something that’s fully automatic most of the time.

16. June 2001Lang. Based Security16 One Approach Restrict the safety policy to type safety. Necessary for most policies anyway: –cannot execute code or access data for which you do not have a capability. –type systems are a meta-policy that allow programmers to define fine-grained notions of “capability” and “access”. abstract types, interfaces, static scope, etc. Start with a well-typed, high-level program –you have a proof for the high-level code –preserve the proof as you compile

17. June 2001Lang. Based Security17 Type-Preserving Compilation Source code Type-checker Proof of type-safety Optimizer Code- generator binary Proof of type-safety

18. June 2001Lang. Based Security18 Touchstone [Necula] Compiles type-safe subset of C to certified binaries for the DEC Alpha. Security policy is type-safety: –parameters of the right type to functions –values of the right type in arrays, structs –array indices in bounds Highly-optimizing –competitive with GCC, DEC cc –eliminates array bound checks when possible

19. June 2001Lang. Based Security19 Touchstone Performance In spite of the fact that C compilers do not insert array bound checks, Touchstone is competitive.

20. June 2001Lang. Based Security20 Touchstone Compilation Time Geometric means: –compilation 75% –VC generation 2% –proving 21% –proof checking 2%

21. June 2001Lang. Based Security21 JVM vs. Touchstone JVM: –portable –$$$ Touchstone: –extremely good performance –extremely small TCB –fast verification

22. June 2001Lang. Based Security22 However... Touchstone’s type system suits only one very simple language: –no abstract data types, objects, etc. –no threads Proof size was an issue: –proofs were 1-3x the size of the code, just for a really simple notion of type-safety. –but recent work by Necula shows that this can be compressed down to tiny overhead (e.g., 10%)

23. June 2001Lang. Based Security23 Touchstone proof size Touchstone’s proof size relative to code and invariant annotations.

24. June 2001Lang. Based Security24 Summary thus far... Proof-carrying code is great in principle. –It’s the right general framework. –For special-purpose applications, can’t be beat. But for general-purpose extensions: –Need some way to get the proof automatically (limit policy to type-safety). –Engineering proof size is an issue. –Compiling high-level languages is an issue.

25. June 2001Lang. Based Security25 Design Details Safety policy Certifying Compiler Theorem Prover VC Generator Proof Checker Client Server Untrusted Complex Slow Trusted Simple Fast Proof Invar Code VC Source Logic Code

26. June 2001Lang. Based Security26 Proof Representation Use a variant of LF to represent assertions and proofs. –write down assertion language –write down inference rules for the logic –proof-checking becomes LF type-checking –decouples the logic and assertion language from the verifier. –of course, you still have to establish the soundness and consistency of the logic that you encode within LF. And this is very hard for realistic settings.

27. June 2001Lang. Based Security27 Representing LF Proofs In practice LF proof objects are HUGE. Recent work on proof oracles compresses this down to nothing [PoPL’2001?] –assume you can match the goal against the conclusions of the proof rules (e.g., 1 st -order unification.) If you can’t match with this, then force the representation to contain more information –only some (small) subset of the rules will apply (say k of them.) –so you only need to spit out lg(k) bits to indicate which rule is actually used in the proof. –the matching lets you then establish sub-goals that need to be proven.

28. June 2001Lang. Based Security28 Where PCC stands Cedilla has built a certifying compiler for Java. –generates optimized x86 code –but you can write your own code too! –uses a Nelson-Oppen-style prover The proof checker is actually machine independent –map object code up to a machine-independent IL (Secure Assembly Language) –proofs are with respect to that the SAL code –retargeting the prover to another machine just involves writing a (correct) mapping from the machine code to SAL.

29. June 2001Lang. Based Security29 Foundational PCC [Appel, Felty] Eliminate more trust from PCC: –logic encoded into LF –implicit machine semantics Rather, encode things from the machine semantics up. –you prove w.r.t. the semantics that {Pre}C{Post} is valid. Interesting observation: –to do any reasonable proof, you start introducing “types” or invariants that look suspiciously like TAL –except that you have a semantic encoding as to what the TAL types mean w.r.t. the machine.