Language-Based Security Proof-Carrying Code

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

2. 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). Lang. Based Security

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

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

5. Unfortunately... trusted computing base NuPRL Lang. Based Security

6. Observation Finding a proof is hard, but verifying a proof is easy. Lang. Based Security

7. could be you PCC: trusted computing base verifier Security Policy optimizer System Binary machine code prover “certified binary” code in- variants proof Lang. Based Security

8. 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. Lang. Based Security

9. 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. code in- variants proof “certified binary” Lang. Based Security

10. 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 code in- variants proof “certified binary” Lang. Based Security

11. 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. code in- variants proof Lang. Based Security

12. 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) Lang. Based Security

13. Results: PCC wins: Lang. Based Security

14. 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? Lang. Based Security

15. 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. Lang. Based Security

16. 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 Lang. Based Security

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

18. 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 Lang. Based Security

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

20. Touchstone Compilation Time • Geometric means: • compilation 75% • VC generation 2% • proving 21% • proof checking 2% Lang. Based Security

21. JVM vs. Touchstone JVM: • portable • $$$ Touchstone: • extremely good performance • extremely small TCB • fast verification Lang. Based Security

22. 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%) Lang. Based Security

23. Touchstone proof size Touchstone’s proof size relative to code and invariant annotations. Lang. Based Security

24. 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. Lang. Based Security

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

26. 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. Lang. Based Security

27. 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., 1st-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. Lang. Based Security

28. 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. Lang. Based Security

29. 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. Lang. Based Security