Scaling Proof-Carrying Code to Production Compilers and Security Policies

1. Scaling Proof-Carrying Code to Production Compilers and Security Policies Zhong Shao Yale University Andrew Appel Princeton University Edward Felten Princeton University February 2001

2. Problem & Motivation How to enforce advanced security policies in the presence of malicious mobile code? Why ? • The world is getting more net-centric (Sun “the network is the computer”; Microsoft .NET) • Mobile code will define the platform (e.g., Java VM, Microsoft Common Language Runtime)

3. Mobile code can: Overwrite memory Read private memory Create machine code and jump to it Execute illegal instructions Obtain control Infinite-loop (in a system without interrupts) …… Abuse of API calls: Read files on disk Write files on disk Obtain critical locks Denial of service Perform operations without holding required lock …… Mobile Code Threats & Attacks

4. Execute no more than N instructions between API calls Hold at most N locks at once Read/write only from readable/writable locations Sequence API operations according to a security automaton [Schneider] Any packet sent must be a copy of some packet received Any message sent must be logged to a file Domain specific ones: don’t withdraw more than $100 from my bank account Moral: need something more powerful than JVM, SFI, sandboxing, … The traditional notion of “type safety” is not enough ! Examples of Advanced Security Policies

5. Code Verifier OK JIT Compiler native code Trusted Computing Base Execute Core Runtime (e.g., garbage collector) The “verifier” is not the whole story: the JIT, core runtime and core API must not break the “security policy” ! Core API Mobile Code System: A Closer Look Bytecode Code Producer Host Environment Source Program load r3, 4(r2) add r2,r4,r1 store 1, 0(r7) store r1, 4(r7) …… Compiler Bare HW (disk,net-acc,…)

6. Our Approach Proof-carrying code Code Producer Host Environment Source Program Certifying Compiler $-i( -i(... -r ... PCC Checker OK load r3, 4(r2) add r2,r4,r1 store 1, 0(r7) store r1, 4(r7) …… native code Execute We directly certify machine code ! We use logic to formally specify “security policies” Core Runtime (e.g., garbage collector) Core API Bare HW (disk,net-acc,…)

7. Our Approach (cont’d) Code Producer Host Environment Foundational PCC Source Program Certifying Compiler $-i( -i(... -r ... FPCC Checker OK load r3, 4(r2) add r2,r4,r1 store 1, 0(r7) store r1, 4(r7) …… native code Execute We construct our security policies and proofs from First Principles --- the standard “higher-order predicate logic” Core Runtime (e.g., garbage collector) Core API Bare HW (disk,net-acc,…)

8. Our Approach (cont’d) Code Producer Host Environment Foundational PCC Source Program Certifying Compiler $-i( -i(... -r ... FPCC Checker OK load r3, 4(r2) add r2,r4,r1 store 1, 0(r7) store r1, 4(r7) …… native code Execute Low-level runtime services and APIs can be certified and moved into a library ! Bonus: the host VM is now lean & extensible ! Certified Library tiny core runtime Bare HW (disk,net-acc,…)

9. Size of Trusted Computing Base PCC system, optimizing compiler Highly optimizing Java Compiler Open-source JVM, non-optimizing JIT

10. Smallest imaginable TCB Foundational Proof-Carrying Code

11. “Conventional” vs. Foundational PCC Warning: these are research goals, not measurements of a built system. Your mileage may vary.

12. Project Organization Felten, Appel Princeton U. Distributed Authentication Frameworks: Proof-Carrying Authentication Appel, Felten Princeton U. Mobile Code Security: Proof-Carrying Code Shao Yale U. Certifying Compilers: FLINT/Java FLINT/ML Language- & machine- independent mobile code safe lang. interop. Secure Key Distribution File servers Secure Linking PCC systems for Java, ML

13. Hints PCC System: A Closer Look Code Producer Code Consumer Native Code Certifying Compiler Source Program Execute load r3, 4(r2) add r2,r4,r1 store 1, 0(r7) store r1, 4(r7) add r7,0,r3 add r7,8,r7 beq r3, .-20 Policy Policy Safety Theorem Safety Theorem Safety Proof Prover $-i( -i(... -r ( ...) ) ) OK Checker

14. type-check type-check type-check type-check type-check Phases of a Compiler Traditional compiler Certifying compiler Source Program type-check Parse, Semantic untyped High-level intermed. lang (IL) Analysis, Optimization untyped Medium-level IL Code Generation untyped Low-level IL Register Allocation untyped Typed Machine Language

15. prove prove prove prove specify Construction of Proofs for PCC Typed machine language Theorems for TAL Semantics of machine-level types Type System Semantics of abstract machine instructions Abstract machine Low-level semantics of machine instructions Opcode decoding Machine Code - sequence of integers

16. Year 1 Year 2 Year 3 Compiler-Prover Interface Source Program Parse, Semantic High-level IL Analysis, Optimization Compiler Medium-level IL Code Generation (Yale) Low-level IL Register Allocation Typed machine language Theorems for TAL Semantics of machine-level types Type System Prover Semantics of abstract machine instructions Abstract machine (Princeton) Low-level semantics of machine instructions Opcode decoding Machine Code - sequence of integers

17. type-check type-check type-check The FLINT Certifying Compiler ML Java Add new front-ends to build new certifying compilers ! Safe C Parse & semantic Parse & semantic Parse & semantic Goal: to build a FLINT VM that uses low-level typed mobile code, and can run on any device ! Currently used & released by SML/NJ; the Java and C front-ends are under active development. High-level FLINT Analysis & Optimization Medium-level FLINT Code Gen. Low-level FLINT Hints Safety Theorem Theorem Prover Program for execution

18. FLINT as a common typed IL

19. FLINT meets FPCC • Relevant problems: • How to specify policy • How to prove consistency of policy • Reference implementation of host-side of API • Strategies to generate & prove code conformant with policy • New version of FLINT can express invariants, props & proofs in its type system: • Use Curry-Howard Isomorphism • Typed FPCC is more user-friendly and scalable • Backward compatibility with existing APIs (e.g., JVM)

20. Theoretical foundations Models for security policies in proof-carrying code Indexed model of recursive types Fully reflexive intensional type analysis in type-erasure semantics [TIC’00] Type-preserving compilation of Mini-Java [FOOL’00] Type-preserving GC [POPL’01] & Principled scavenging [PLDI’01] A generic framework for certified binary Progress on implementation Built proof-carrying authorization prototype (browser/webserver) Indexed model of types Mutable fields Typed machine language Prototype JVML-to-FLINT compiler Prototype typesafe GC New FLINT backend with proof-passing typed ILs Main Technical Results (last 6 months)

21. Web server/browser prototype get http://... Web Server Custom Proxy Server Browser authenticate proof web page Prover Checker • Built by Felten and students (Bauer, Schneider) at Princeton • Implementation is complete • Flexible, extensible, general • Can’t probe system for axioms (security policy available to client on a need-to-know basis)

22. Components of PCA prototype Client Server Web browser HTTPproxy HTTP server Hintserver Prover Prop.Gen. Checker COTS components Custom Java code Twelf system from CMU

23. Sample exchange: access a protected page Alice : GET https://server/midterm.html Client (Alice) Server (Bob) Web browser HTTPproxy HTTP server Hintserver Prover Prop.Gen. Checker HTTPS protocol allows secure transmission and session IDs

24. Server: Generate the goal to be proved P1 = says @ (key @ “serverkey”) @ (goal @ “https://server/midterm.html” @ “sid”) Client (Alice) Server (Bob) Web browser HTTPproxy HTTP server Hintserver Prover Prop.Gen. Checker

25. Server: Challenges; Client: Proofs Client (Alice) Server (Bob) Web browser HTTPproxy HTTP server Hintserver Prover Prop.Gen. Checker Authorization required: prove P1 : Bob

26. Client: Generate the proof • Self-signed assumptions • ACLs • Server time • Hints Client (Alice) Server (Bob) Web browser HTTPproxy HTTP server Hintserver Prover Prop.Gen. Checker

27. Client: send the proof Alice : GET https://server/midterm.html pf (says @ (key @ “serverkey”) @ (goal @ “http://server/midterm.html” @ “sid”)) = … Client (Alice) Server (Bob) Web browser HTTPproxy HTTP server Hintserver Prover Prop.Gen. Checker

28. Server: check the proof, serve the request Alice : GET https://server/midterm.html pf (says @ (key @ “serverkey”) @ (goal @ “http://server/midterm.html” @ “sid”)) = … Client (Alice) Server (Bob) Web browser HTTPproxy HTTP server Hintserver Prover Prop.Gen. Checker Here you go: midterm.html : Bob

29. Project Summary (Four Questions) • Threats & attacks we consider: • Malicious mobile code; abuse of API calls • Assumptions we make: • Policies employed use consistent rules • Proofs are based on consistent axioms • Hardware & code in (minimized) TCB are “well-behaved” • Policies we can enforce: • Any security policies with formal specifications (expressible in Higher-Order Predicate Logic)

30. Conclusions • Mobile code will define the platform (e.g., JVM, .NET) • Enforcing “advanced” security policies requires building “new infrastructure”: • Certifying compiler for mainstream languages (Java, C) • Efficient prover and checker • Tools & libraries that facilitate certified programming But the payoff is huge ! • Highly extensible & secure runtime (w. tiny kernel) • Language- & platform-indep. certified code&proof libraries • Making it practical is challenging but extremely promising • Don’t have to deploy the whole thing in one day • Technologies for compiler & theorem-proving are quite mature • Most security policies are simple (not for “full correctness”)