Proof Carrying Code

1. University of Konstanz Department of Computer and Information Science Prof. Dr Stefan Leue, Wei Wei Verified Software Security WS 2005/2006 Proof Carrying Code Presented by Giannakaras Giorgos

2. Outline • Motivation • Overview • Example • Assesment

3. Motivation • Problem :The execution of a program from a code consumer, supplied by an untrusted code producer, may produce undesirable effects. • Distributed and Web computing : For mobile code the code consumer could be an Internet host (e.g. web browser) and the code producer a server that sends applets. How can the server convince the web browser that the received code is safe to be executed? • Operating Systems : The kernel acts as a host and untrusted applications act as code producers that download and execute code in the kernel’s address space. How can the kernel be convinced that the code produced by the applications won’t act maliciously?

4. Motivation • How do we guarantee the safety of the foreign code? • Cryptography : A mechanism that can be used to ensure that a code was produced by a trusted person or compiler. • This scheme is weak because even trusted persons or compilers written by them can make errors or even act maliciously. • Run-time checking : A mechanism that can be used to check errors at runtime, e.g. arithmetic overflows or invalid type casts. Most time an exception is thrown terminating the program. • This scheme slows down the resulting program so it’s not very efficient due to the run-time cost we have.

5. Motivation Solution : Proof Carrying Code (PCC) • The code consumer defines a safety policy. • The code producer creates a safety proof that attests to the fact that the code respects the formally defined safety policy. • The code consumer uses a simple and fast proof validator to check whether the proof is valid and if so the code is executed.

6. Overview of Proof-Carrying Code

7. Safety Policy Consists of 2 main components : • Safety rules : All authorized operations and their associated safety preconditions. • Interface : Calling conventions between the code consumer and the foreign program described in terms of the invariants. Analogy with types : • Safety rules Typing rules • Interface Signature Pre ≡ rm ├ r0 : T list Post ≡ rm ├ r0 : int

8. PCC Binary • Certification : • The code producer compiles and generates a proof that a source program adheres to the safety policy. • The safety proof together with native code component form the PCC binary.

9. PCC Binary • Validation : • The code consumer validates the proof part of a PCC binary presented for execution and loads the native code component for execution. • The existence of the proof allows for the verification process to be performed off-line and only once for a given program.

10. PCC Binary • Execution of code: • The code consumer executes the machine-code program possibly many times. • The stage can proceed without additional run-time checks.

11. Example • Description : We want to extend the run-time system of the TIL compiler for standard ML, writing safe assembly code with the use of PCC. • ML Language : ML is a functional language type-directed. • Assignment to variables is not possible. • There are no control flow operations (loops, goto statements e.t.c)

12. Example Source Code (in ML) datatype T = Int of int | Pair of int * int fun sum (l : T list) = let fun foldr f nil a = a | foldr f (h::t) a = foldr f t (f(a, h)) in foldr (fn (acc, Int i)) => acc + i | (acc, Pair(i, j)) => acc + i + j) 1 0 end

13. Establishing a Safety Policy • Data type definition : datatype T = Int of int | Pair of int *int • Defining the involved types : τ ::= int | τ1* τ2 | τ1 + τ2 | τ list Semantics : • τ1* τ2 pair of τ1and τ2 • τ1+ τ2 either τ1or τ2 • Hence T = int + (int * int)

14. Establishing a Safety Policy Data representation in TIL • Integers values are represented as untagged integer 32-bit machine words. • A pair is represented as a pointer to a sequence of 2 memory locations containing values of appropriate types. • A value of type τ1 + τ2 is represented as a pointer to a pair of locations containing respectively the constructor value (0 and 1) and the value carried by the constructor • The empty list is represented as the value 0 and the non-emtpy list as a pointer to a list cell.

15. Establishing a Safety Policy Definition of expressions and memory states. • m├ e : τ • m : memory state • e : expression • τ : datatype • e ::= n | ri | sel(m, e) | e1 + e2 • n : 32-bit integer literal • ri : DEC Alpha machine registers • sel(m, e) : denotes the contents of the location e in memory state m • m ::= rm | upd(m, e1, e2) • rm: pseudo register holding the state of memory during the computation • upd(m, e1, e2) : denotes a memory state obtained from the old state m after updating the location e1 with e2. New datatype included : • addr : for memory locations that can be safely read

16. Establishing a Safety Policy The typing rules

17. The Foreign Function • The code producer writes an assembly language implementation of the sum function, that adds all the integers in a T list. • The code is written in such a way to obey the TIL data-representation and this fact must be proved for the consumer. • r0 contains the argument of type T list on entry and the integer result on exit. • r1, r2, r3 are temporary registers. • Program is viewed as a vector Π of instructions. • INV is a pseudo instruction denoting invariants at various program points.

18. Verification Condition • The basic method to check compliance with the safety rules is based on computing a Floyd-style verification condition for the foreign function. • This is a predicate in first-order logic with the property that its validity with respect to the first-order rules and the typing rules is a sufficient condition for ensuring compliance with the safety policy. • Goal of the verification condition is to reach from the precondition to the postcondition of the program. • Computed by both the code-producer and the code-consumer. • Floyd-style verification condition generator needs all the loop invariants, a precondition and a postcondition as well.

19. Verification Condition • The interface for the function sum is given as a precondition and a postcondition : Pre ≡ rm ├ r0 : T list Post ≡ rm ├ r0 : int • The set of all invariants is denoted as Inv and Invi corresponds to an invariant at point i of the program. • The code consumer prepends the instruction INV to each untrusted program before analyzing it.

20. Verification Condition Generator • The verification condition generator computes a vector VC of predicates one for each instruction. • The notation [e/ri]P stands for the predicate obtained from P by substituting the expression e for all occurrencies of ri. • The VC function is well defined if every loop in the program contains at least one invariant instruction.

21. Program Verification Condition • Based on the vector VC, the verification condition for the entire program is defined as follows:

22. Generating Verification Condition ri(Inv0 VC1 Inv2 VC3)

23. Generating Verification Condition Inv0 VC1 Inv0 [ 0/r1 ]VC2

24. Generating Verification Condition Inv2 VC3 VC3 ( (r0 = 0 VC15) (r0 != 0 VC4) ) VC3 ( Post (r0 != 0 VC4) )

25. Soundness of VC-based Certification We need to show that : Every memory read operation references a readable address and that uppon termination the post condition holds. We formalize with the above theorem : For any program Π, set of invariants Inv and postcondition Post such that Π0 = INV Pre, if ►VC(Π, Inv, Post) and the initial state satisfies the precondition Pre, then the program reads only from valid memory locations as they are defined by the typing rules, and if it terminates, it does so in a state satisfying the postcondition.

26. Assesment of PCC Advantages : • The effort of establishing and formally proving the safety of the mobile code is shifted to the code producer. • The code consumer performs a fast, simple and easy to trust proof-checking process. • The code consumer doesn‘t care how the proofs are constructed. • Any modification to PCC programms (accidental or malicious) will have the following results : • The proof will no longer be valid and the program will be rejected. • The proof will be valid but will no more be a safety proof for the program and the program will be rejected. • The proof will still be valid and there will still be a safety proof for the program.

27. Assesment of PCC Advantages : • There is no need for cryptography because PCC is checking the intrinsic properties of the code and not it‘s origin. • We save time because the untrusted code is verified before being executed, so we detect hazardous operations early. Disadvantages : • There might be a large amount of effort and difficulties in establishing and formally proving the safety of the mobile code by the code producer. • We can`t verify the lifeness of a program. We can‘t prove that the program will finally terminate.

28. END OF PRESENTATION